Chronological Thread 

< Chronological >      < Thread >

---

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

---

• [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+.