Chronological Thread 

< Chronological >      < Thread >

---

Andreas,

Thanks for your comments again. Especially the "Ugh" :-).

Let me try to clarify my intentions and motivations. I am
considering an
sctpd-like daemon that is a more customized fit to my application.
So far, it seems that the additional work required will be minimal,
and I might get some throughput improvement. In general, I shy away
from making modifications to sctplib code because of the upkeep
issues and my inexperience with the code.

In my SCTP daemon I am make a distinction between two I/O sides:
the wire side which is the SCTP protocol and the IPC side.

In method A described below, the IPC side communications is divided
between sctplib
for inbound messages, and a proprietary method for outbound
messages. This creates an exceptional IPC interface in my
application that I would like to avoid if possible.

In method B described below, I use sctplib for the wire side
communications and to use a proprietary method for IPC
communications.

Method B works by alternating between sctplib's non-blocking poll of
its events (sctp_getEvents) and the IPC method's non-blocking poll
of its events (for example, ipc_getEvents). A
queue is implemented to absorb the flow of messages in the SCTP to
IPC direction.
sctplib is already capable of absorbing messages in the IPC to SCTP
direction.

I find Method B attractive for the following reasons:
1) Keeping sctplib independent of IPC allows me to more easily
change to the socket style API that is being developed. It seems
plausible that this interface will become dominant in the future.
2) I want to avoid waiting around in a poll or select call for
events to occur. I prefer to bounce back and forth between checking
on sctplib events and IPC events.
3) I can reuse an IPC method that is already adapted to my
application.

Tests this morning show that:
1) sctp_registerUdpCallback works when sctp_getEvents is used. I
was just curious about this possibility even though I do not intend
to use this capability right now.
2) Method B appears to function correctly

The main code chunk of the daemon I tested is attached. You will
recognize the code because it is based on echo_server.c. I added
code segments to test the items above. I tested by running my
application with this daemon on 192.168.1.4. I ran terminal on
192.168.1.3. I also injected messages to the IPC portion using a
facility written in Python. Using two windows on 192.168.1.3 I was
able to run terminal and the IPC injector simultaneously. I will
provide more supporting files to the daemon if there is interest.

Mike


----- Original Message -----
From: "Andreas Jungmaier"
<ajung AT exp-math.uni-essen.de>
To:
<discussion AT sctp.de>
Sent: Wednesday, November 28, 2001 6:10 AM
Subject: Re: [SCTP-Discussion] sctp_eventLoop vs sctp_getEvents


: -----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-----
: _______________________________________________
: discussion mailing list
:
discussion AT sctp.de
: http://www.sctp.de/mailman/listinfo/discussion

Attachment: sctp_d_main_x.cpp
Description: Binary data

---

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