Chronological Thread 

< Chronological >      < Thread >

---

see my comments to the last question by Michael,

-----Original Message-----
From: Tuexen Michael ICN WN CS SE 51
Sent: Wednesday, August 29, 2001 4:20 PM
To:
'discussion AT sctp.de'
Subject: RE: [SCTP-Discussion] sctpd, sctplib, and IPC


Dear all,
see my comments below.
Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Michael Mueller
> [SMTP:bhu5nji AT yahoo.com]
> Sent: Wednesday, August 29, 2001 3:33 PM
> To:
> discussion AT sctp.de
> Subject: [SCTP-Discussion] sctpd, sctplib, and IPC
>
> My impression of sctpd is that it is a daemon that manages multiple
> SCTP instances for clients through a UDP interfaces. Is this
> correct?
[Tuexen Michael] Yes.
> The User Manual, mentions that it is possible to run multiple
> instances of SCTP using different IP addresses. Is this the only
> method for managing multiple IP addresses with sctplib?
[Tuexen Michael] No. All instances are able to
handle multipe IP-Addresses (IPv4/IPv6). The point
is that you can not run multiple instances of the
library with common IP-Addresses.
>
> How does sctpd transfer chunks to other processes? Is it
> implementation dependent? Here is how I think that it would be
> done:
[Tuexen Michael] It uses a UDP based communication.
> Consider a system with two daemons where one is running sctplib
> (called d-sctp to differentiate it from sctpd) and the other is
> running a user application (called d-ua). The two processes
> communicate with each other using UDP sockets. Do the following
> sctplib design choices make sense in this situation?
>
> 1. d-sctp uses helper function sctp_registerUdpCallback() to cause
> sctp_eventLoop() to create/bind/watch for UDP input on
> 127.0.0.0:50023. The callback function transfers information from
> the UDP datagram to an SCTP stream.
[Tuexen Michael] What is wrong with this?
> 2. d-sctp will create/bind a UDP socket on 127.0.0.0:50024.
[Tuexen Michael] This seems not to be necessary.
> 3. d-ua sends to d-sctp on 127.0.0.0:50023 and receives from d-sctp
> on 127.0.0.0:50024.
[Tuexen Michael] The d-sctp could only use one
UDP socket.
> 4. d-sctp has a function defined for function pointer
> (*dataArriveNotif)() that will transfer all incoming SCTP chunks to
> 127.0.0.0:50024 if the socket is write-ready; if the socket is not
> write ready, then the chunk is placed into a queue.
[Tuexen Michael] That is OK, isn't it?
> 5. d-sctp uses the Timer helper functions to periodically service
> the IPC queue mentioned in 4 above. If the queue has chunk entries,
> then they will be sent to d-ua if the socket is write-ready.
[Tuexen Michael] Seem reasonable. You have to avoid
the blocking of a system call if you use the callback
interface.
> Thanks again,
> Mike
[Tuexen Michael] Maybe we get some info why multiple UDP
sockets are used from the developers of the sctpd?



[Woon Chiat] The reason now why two UDP sockets were used is that there are
two types of messages that user applications need to receive from the
daemon. These are notification of sctp events and responses to the requests
made by user apps. The udp port used for receiving notifications is
monitored by the SCTP library's event loop. Usually, when the user app makes
a request to the daemon, the library function provided by the sctpd library
blocks until the response comes back. This is to maintain the same format of
function call - return value used by the sctp library.

However, since the notification port is monitored by the sctp event loop, we
cannot use it anymore to receive responses coming back from the daemon to
the user app (one reason being that it is already bound to a socket at that
point in time). Note also that the sctp event loop is block at this point in
time. Hence, another port is needed.

i won't go into whether this is a good design, but suffice to say that it is
being looked into. This design decision was made when the daemon was in its
very early stage of development.. when it wasn't even known as a daemon. :-)

hope this is a good enough explanation.

cheers
wc






Best regards
Michael
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion
_______________________________________________
discussion mailing list
discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/discussion

---

• [SCTP-Discussion] sctpd, sctplib, and IPC, Michael Mueller, 08/29/2001
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] sctpd, sctplib, and IPC, Tuexen Michael, 08/29/2001
  • RE: [SCTP-Discussion] sctpd, sctplib, and IPC, Sim Woon Chiat ICM CA MS MI E7 Extern, 08/29/2001
    • Re: [SCTP-Discussion] sctpd, sctplib, and IPC, Michael Mueller, 08/29/2001
  • RE: [SCTP-Discussion] sctpd, sctplib, and IPC, Sim Woon Chiat ICM CA MS MI E7 Extern, 08/30/2001

---

Archive powered by MHonArc 2.6.19+.