Chronological Thread 

< Chronological >      < Thread >

---

I have couple of queries regarding the new implementation of SCTP daemon:
As far as my understanding is correct, there will be three UDP sockets for
ULP -SCTPDaemon
communication with ports UDP_App_Port,UDP_Return_Port and
sctpUdpListeningPort..
Socket1 (PortID:UDP_App_Port) is used for notification from SCTP daemon to
ULP
Socket2 (PortID:UDP_Return_Port) is used to send response from SCTP Daemon to
ULP
and Socket3 (PortID:sctpUdpListeningPort) is for sending data from ULP to
SCTP daemon...
SCTP daemon will poll on descriptor for socket3(PortID:sctpUdpListeningPort.).
Iam i right?
If so my question is :
It is which process's responsibilities to poll on socket1( UDP_App_Port).
Looks like
its user apps jobs( bcoz cudn'nt locate adl_register_fd_cb() for file
descriptor for this UDP port in )..
BUt the previous mail says that sctp daemon's event loop will poll this
socket.. iam bit confused about this.. wud you pls calrify why SCTP daemon
should POLL this socket?Isn't it user apps's job to do this?
But if the uses apps is going to POLL on UDP_App_Port & UDP_Return_Port.
can't we have just one socket to send data to user apps(i.e notification as
well as response)
Also could you please clarify the reason why any API call to sctp( to send
data on UDP socket-SCTPListPOrt) should be a blocked till we get response
from the SCTP daemon

thanks in advance,
ashraf

On Thu, 30 Aug 2001 12:01:17
discussion-request wrote:
>Send discussion mailing list submissions to
>
> discussion AT sctp.de
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://www.sctp.de/mailman/listinfo/discussion
>or, via email, send a message with subject or body 'help' to
>
> discussion-request AT sctp.de
>
>You can reach the person managing the list at
>
> discussion-admin AT sctp.de
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of discussion digest..."
>
>
>Today's Topics:
>
> 1. an small error in daytime_server.c (wu zhen)
> 2. sorry, the error is corrected i pre14! (wu zhen)
> 3. Unsubscribe Request. (Papotti Luca)
> 4. sctpd, sctplib, and IPC (Michael Mueller)
> 5. RE: sctpd, sctplib, and IPC (Tuexen Michael)
> 6. RE: sctpd, sctplib, and IPC (Sim Woon Chiat ICM CA MS MI E7 Extern)
> 7. Re: sctpd, sctplib, and IPC (Michael Mueller)
> 8. RE: sctpd, sctplib, and IPC (Sim Woon Chiat ICM CA MS MI E7 Extern)
>
>--__--__--
>
>Message: 1
>From: "wu zhen"
><wuzhen_zq AT sina.com.cn>
>To:
><discussion AT sctp.de>
>Date: Wed, 29 Aug 2001 18:36:49 +0800
>charset="gb2312"
>Subject: [SCTP-Discussion] an small error in daytime_server.c
>Reply-To:
>discussion AT sctp.de
>
>ZnVuY3Rpb246DQp2b2lkIHByaW50VXNhZ2Uodm9pZCkNCnsNCiAgICBwcmludGYoIlVzYWdlOiAg
>IGRpc2NhcmRfc2VydmVyIFtvcHRpb25zXSAtcyBzb3VyY2VfYWRkcl8xIC1zIHNvdXJjZV9hZGRy
>XzIgLi4uXG4iKTsNCiAgICBwcmludGYoIm9wdGlvbnM6XG4iKTsNCiAgICBwcmludGYoIi12ICAg
>ICAgIHZlcmJvc2UgbW9kZVxuIik7ICAgDQogICAgcHJpbnRmKCItViAgICAgICB2ZXJ5IHZlcmJv
>c2UgbW9kZVxuIik7ICAgDQp9DQoNCmluIGxpbmUgNjEsICJkaXNjYXJkX3NlcnZlciIgc2hvdWxk
>IGJlICJkYXl0aW1lX3NlcnZlciINCg==
>
>
>--__--__--
>
>Message: 2
>From: "wu zhen"
><wuzhen_zq AT sina.com.cn>
>To:
><discussion AT sctp.de>
>Date: Wed, 29 Aug 2001 19:37:37 +0800
>charset="gb2312"
>Subject: [SCTP-Discussion] sorry, the error is corrected i pre14!
>Reply-To:
>discussion AT sctp.de
>
>aSBwb3N0IGFuIHVubmVjZXNzYXJ5IG1lc3NhZ2UgZm9yIGRheXRpbWVfc2VydmVyIGVycm9yLg0K
>d2hhdCBpIHVzZSBpcyBwcmUxMywgbm93IGkgaGF2ZSBkb3dubG9hZCBwcmUxNCwNCmFuZCBmb3Vu
>ZCB0aGUgZXJyb3IgaXMgY29ycmVjdGVkIGluIHByZTE0LiBTbyBwbGVhc2UgaWdub3JlIG15IHBy
>ZXZpb3VzIG1lc3NhZ2UuDQo=
>
>
>--__--__--
>
>Message: 3
>From: Papotti Luca
><Luca.Papotti AT italtel.it>
>Organization: Italtel
>To:
>discussion AT sctp.de
>Date: Wed, 29 Aug 2001 13:40:29 +0200
>charset="iso-8859-1"
>Subject: [SCTP-Discussion] Unsubscribe Request.
>Reply-To:
>discussion AT sctp.de
>
>Please deregister me from this m-list. Thank's
>(luca.papotti AT italtel.it)
>
>--__--__--
>
>Message: 4
>From: "Michael Mueller"
><bhu5nji AT yahoo.com>
>To:
><discussion AT sctp.de>
>Date: Wed, 29 Aug 2001 09:32:43 -0400
>charset="iso-8859-1"
>Subject: [SCTP-Discussion] sctpd, sctplib, and IPC
>Reply-To:
>discussion AT sctp.de
>
>My impression of sctpd is that it is a daemon that manages multiple
>SCTP instances for clients through a UDP interfaces. Is this
>correct?
>
>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?
>
>How does sctpd transfer chunks to other processes? Is it
>implementation dependent? Here is how I think that it would be
>done:
>
>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.
>
>2. d-sctp will create/bind a UDP socket on 127.0.0.0:50024.
>
>3. d-ua sends to d-sctp on 127.0.0.0:50023 and receives from d-sctp
>on 127.0.0.0:50024.
>
>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.
>
>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.
>
>Thanks again,
>Mike
>
>
>--__--__--
>
>Message: 5
>From: Tuexen Michael
><Michael.Tuexen AT icn.siemens.de>
>To:
>"'discussion AT sctp.de'"
>
><discussion AT sctp.de>
>Subject: RE: [SCTP-Discussion] sctpd, sctplib, and IPC
>Date: Wed, 29 Aug 2001 16:20:10 +0200
>Reply-To:
>discussion AT sctp.de
>
>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?
>
> Best regards
> Michael
>> _______________________________________________
>> discussion mailing list
>> discussion AT sctp.de
>> http://www.sctp.de/mailman/listinfo/discussion
>
>--__--__--
>
>Message: 6
>From: Sim Woon Chiat ICM CA MS MI E7 Extern
><WoonChiat.Sim.extern AT icn.siemens.de>
>To:
>"'discussion AT sctp.de'"
>
><discussion AT sctp.de>
>Subject: RE: [SCTP-Discussion] sctpd, sctplib, and IPC
>Date: Wed, 29 Aug 2001 16:44:59 +0200
>Reply-To:
>discussion AT sctp.de
>
>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
>
>--__--__--
>
>Message: 7
>From: "Michael Mueller"
><bhu5nji AT yahoo.com>
>To:
><discussion AT sctp.de>
>Subject: Re: [SCTP-Discussion] sctpd, sctplib, and IPC
>Date: Wed, 29 Aug 2001 12:35:15 -0400
>charset="iso-8859-1"
>Reply-To:
>discussion AT sctp.de
>
>Please see my comments on comments by WC below
>Mike
>
>----- Original Message -----
>From: "Sim Woon Chiat ICM CA MS MI E7 Extern"
><WoonChiat.Sim.extern AT icn.siemens.de>
>To:
><discussion AT sctp.de>
>Sent: Wednesday, August 29, 2001 10:44 AM
>Subject: RE: [SCTP-Discussion] sctpd, sctplib, and IPC
>
>
>: 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.
>
>[Mike Mueller] After reading Michael's comments above, I was
>persuaded into thinking that a single socket is sufficient for IPC
>between an sctp daemon and a ua daemon.
>
>If sctpd "owns" the process that is running the sctp event loop,
>then it cannot use the second port when the sctp event loop is
>blocking while waiting for an event.
>
>If a timer expiry or raw socket event causes a return from select
>statement, the ua-to-sctpd socket should be writable using "sendto"
>with flags parameter set to MSG_DONTWAIT for example.
>
>I assume that upon return from a callback function, the sctp event
>loop resets its fd sets and calls select again.
>
>Perhaps I didn't dig deep enough, but in the /sctpd_program examples
>I could not find an example of bidirectional IPC using sctpd. What
>I found in /scptd_programs/sctp_monitor was the callback function
>for arriveNotif making direct calls to Gtk to display to the GUI.
>While that is efficient handling, I was hoping to see the sctp chunk
>sent to the UA via IPC in the arriveNotif callback, and the UA
>making Gtk calls after receiving the chunk via IPC.
>
>Based on this discussion, I will hack up a test and report the
>results.
>
>:
>: 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
>: _______________________________________________
>: discussion mailing list
>:
>discussion AT sctp.de
>: http://www.sctp.de/mailman/listinfo/discussion
>
>
>--__--__--
>
>Message: 8
>From: Sim Woon Chiat ICM CA MS MI E7 Extern
><WoonChiat.Sim.extern AT icn.siemens.de>
>To:
>"'discussion AT sctp.de'"
>
><discussion AT sctp.de>
>Subject: RE: [SCTP-Discussion] sctpd, sctplib, and IPC
>Date: Thu, 30 Aug 2001 08:50:49 +0200
>charset="iso-8859-1"
>Reply-To:
>discussion AT sctp.de
>
>pls see my comments below...
>
>
>-----Original Message-----
>From: Michael Mueller
>[mailto:bhu5nji AT yahoo.com]
>Sent: Wednesday, August 29, 2001 6:35 PM
>To:
>discussion AT sctp.de
>Subject: Re: [SCTP-Discussion] sctpd, sctplib, and IPC
>
>
>Please see my comments on comments by WC below
>Mike
>
>----- Original Message -----
>From: "Sim Woon Chiat ICM CA MS MI E7 Extern"
><WoonChiat.Sim.extern AT icn.siemens.de>
>To:
><discussion AT sctp.de>
>Sent: Wednesday, August 29, 2001 10:44 AM
>Subject: RE: [SCTP-Discussion] sctpd, sctplib, and IPC
>
>
>: 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.
>
>[Mike Mueller] After reading Michael's comments above, I was
>persuaded into thinking that a single socket is sufficient for IPC
>between an sctp daemon and a ua daemon.
>
>If sctpd "owns" the process that is running the sctp event loop,
>then it cannot use the second port when the sctp event loop is
>blocking while waiting for an event.
>
>If a timer expiry or raw socket event causes a return from select
>statement, the ua-to-sctpd socket should be writable using "sendto"
>with flags parameter set to MSG_DONTWAIT for example.
>
>I assume that upon return from a callback function, the sctp event
>loop resets its fd sets and calls select again.
>
>Perhaps I didn't dig deep enough, but in the /sctpd_program examples
>I could not find an example of bidirectional IPC using sctpd. What
>I found in /scptd_programs/sctp_monitor was the callback function
>for arriveNotif making direct calls to Gtk to display to the GUI.
>While that is efficient handling, I was hoping to see the sctp chunk
>sent to the UA via IPC in the arriveNotif callback, and the UA
>making Gtk calls after receiving the chunk via IPC.
>
>
>[Woon Chiat] First off, I need to apologize for a mis-explanation (i was
>rushing when i sent the reply). I should clarify that the User Applications
>(UA) DO NOT use the sctp event loop, only the daemon does. The UAs should
>use whatever event loop that they please to monitor the UDP ports. In that
>case, it may be possible to reuse the UDP ports by playing around with the
>flags, I am not too sure on that point. Note, the daemon uses only one UDP
>port to listen for messages from the UAs.
>
>I hope i have not cause undue confusion here.
>
>anyway, another point is that the sctpdlib is suppose to hide all the UDP
>messaging stuff (except the actual receiving of UDP data for the
>notification messages, which the UA have to provide) from the UA. So, the UA
>would not see the UDP message being sent.
>
>A document is being worked on that will serve as a guideline on how a UA
>should use the sctpdlib in order to communicate with the daemon. It should
>be in the next release.
>
>
>Based on this discussion, I will hack up a test and report the
>results.
>
>[Woon Chiat] Please do...
>
>cheers
>wc
>
>
>:
>: 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
>: _______________________________________________
>: 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
>
>
>--__--__--
>
>_______________________________________________
>discussion mailing list
>discussion AT sctp.de
>http://www.sctp.de/mailman/listinfo/discussion
>
>
>End of discussion Digest_______________________________________________
>discussion mailing list
>discussion AT sctp.de
>http://www.sctp.de/mailman/listinfo/discussion
>


Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/

---

• [SCTP-Discussion] Re: discussion digest, Vol 1 #145 - 8 msgs, Mohammed P.A Ashraf , 09/05/2001
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] Re: discussion digest, Vol 1 #145 - 8 msgs, Yeo Choon Kiat ICM CA MS MI E7 Extern, 09/06/2001

---

Archive powered by MHonArc 2.6.19+.