Chronological Thread 

< Chronological >      < Thread >

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> This distinction allows another solution to handling non-blocking
> I/O for IPC between an sctplib based daemon and an sctp consumer
> daemon. I see two methods of managing non-blocking IPC:

I must admit that at the time I wrote these functions, I have
not thought about non-blocking IPC.

> A) Using sctp_eventLoop, a message arriving on the wire needing to
> be sent via IPC to the consumer daemon is blocked from writing on
> the IPC socket. The datagram must be enqueued for tranmission at a
> later time. An sctplib timer is activated to cause return to the
> IPC function periodically until the datagram is sent.

That would certainly be possible. I realize that this solution is
not very pretty. We wanted something that worked fast.
Basically, in a more advanced implementation, we would probably
end up using a queue for IPC messages.

> B) Using sctp_getEvent, the sctplib application in the sctplib based
> daemon runs a forever loop that alternately calls sctp_getEvents and
> a local function or object method to handle non-blocking IPC. In
> this method, sctp_registerUdpCallback is unneeded because there is a
> local IPC handler. When a message arrives on the wire it is placed
> in an IPC queue. When the IPC handler gets its turn to run, it
> polls the IPC socket write side, and if it is ready, the handler
> extracts the message from the IPC queue and sends it to a peer
> daemon using the socket. The IPC handler also checks the read side
> of the socket and reads the socket if it is ready. Inbound
> datagrams are submitted to sctplib via sctp_send. The key to this
> method is that neither sctp_getEvent nor the IPC handler wait around
> for events.

Ugh, that is really hard to follow (sorry, I am not exactly sure
what daemon you are referring to etc.)
Reading the poll man page I find:
The following possible bits in these masks are defined
in <sys/poll.h>
#define POLLIN 0x0001 /* There is data to read */
#define POLLPRI 0x0002 /* There is urgent data to read */
#define POLLOUT 0x0004 /* Writing now will not block */
#define POLLERR 0x0008 /* Error condition */
I suspect that you could just modify the {struct pollfd} that is set
for UDP in the poll() call we use, and the poll() would return, once
POLLOUT is true. I am, however, not exactly sure whether that works
with non-blocking calls, or as to the portability (some OSs do not
have poll and emulate poll by a select() call)

If you find a way to make this work, you can send me code, and I
will try to include that in a later release.

Best regards,
Andread


- --
- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier | _
Computer Networking Technology Group | ASCII ribbon campaign ( )
University of Essen | - against HTML email X
http://www.exp-math.uni-essen.de/~ajung | & vcards / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8BMYmXAsLBNOCSsARAjCSAJ9i6bnCQOyJn0Ygr6LGFk2kYltA+ACg3Kv4
LGwLL67Z+0iug7dl9C2gZ4c=
=6yj0
-----END PGP SIGNATURE-----

---

• [SCTP-Discussion] sctp_eventLoop vs sctp_getEvents, Michael Mueller, 11/27/2001
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] sctp_eventLoop vs sctp_getEvents, Tuexen Michael, 11/27/2001
    • Re: [SCTP-Discussion] sctp_eventLoop vs sctp_getEvents, Michael Mueller, 11/27/2001
      • Re: [SCTP-Discussion] sctp_eventLoop vs sctp_getEvents, Andreas Jungmaier, 11/28/2001
        • Re: [SCTP-Discussion] sctp_eventLoop vs sctp_getEvents, Michael Mueller, 11/28/2001

---

Archive powered by MHonArc 2.6.19+.