Chronological Thread 

< Chronological >      < Thread >

---

Dear Michael,

Thank you. Your comment forced me to take another look at the
"poll" call in sctp_getEvents. I now see the timer is set to 0 so
that there is no waiting around for an event. So now a distinction
between the sctp_eventLoop and sctp_getEvents can be drawn based on
lingering in "poll" or not lingering respectively.

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:

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.

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.

My tests suggest method A works just fine. Using method A means
that I must have two sockets for IPC with the sctp daemon - one for
inbound messages and one for outbound messages. The inbound socket
is created by sctp_registerUdpCallback (who keeps the socket fd
private). My application creates the outbound socket. Elsewhere in
my set of daemons, there is a special two-socket method for IPC with
the sctp daemon. I am also concerned that throughput may be
mitigated by the timed waiting in the calls to "poll".

I am curious about method B because I am interested in fully
managing non-blocking IPC while using sctplib in a daemon. This
means that I can use a single socket for bidirectional IPC, which is
how I manage all IPC in my application currently. I also have a
sense that alternating between sctp_getEvents and the IPC handler
without timed waits will improve throughput by using processing time
slices to move bytes.

Is my proposed application of sctp_getEvents reasonable?

Can I use sctp_registerUdpCallback with sctp_getEvents (even though
I just explained why I would not do this)?

Can I use sctp_startTimer and the suite of timer functions with
sctp_getEvents?

Best regards,
Michael Mueller

----- Original Message -----
From: "Tuexen Michael"
<Michael.Tuexen AT icn.siemens.de>
To:
<discussion AT sctp.de>
Sent: Tuesday, November 27, 2001 3:14 AM
Subject: RE: [SCTP-Discussion] sctp_eventLoop vs sctp_getEvents


: Dear Michael,
:
: it is not deprecated or obsolete, just not needed in
: the examples.
:
: I assume that the processing of the callbacks do not
: take long. So the programs do not do any event processing
: during the callback processing.
:
: 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: Tuesday, November 27, 2001 7:22 AM
: > To:
discussion AT sctp.de
: > Subject: [SCTP-Discussion] sctp_eventLoop vs sctp_getEvents
: >
: > After looking at the documentation for sctplib, sample programs,
and
: > adaptation.c, I get the impression that sctp_getEvents is
: > deprecated and maybe even obsolete. Is this the correct
impression?
: >
: > Mike
: >
: >
: > _______________________________________________
: > 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] 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+.