- 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] sctp_registerUdpCallback
- Date: Fri Nov 16 11:32:01 2001
- List-id: SCTP Discussions <discussion.sctp.de>
hi,
it is possible to use more than one association in each user application of
the sctpd.
The simple reason is that what the UDP messaging does is just to send the
notifications and function calls with their associated parameters to and
from between the daemon and the user applications. If you look at the API of
the sctplib, in cases where it is significant to know which association the
notification or function call relates to, the assoc ID is usually provided
as one of the paramter. Like other parameters, it will be passed between the
daemon and the user application. There is no need to change the "protocol".
hope this answers your question.
wc
-----Original Message-----
From: Michael Mueller
[mailto:bhu5nji AT yahoo.com]
Sent: Thursday, November 15, 2001 10:04 PM
To:
discussion AT sctp.de
Subject: Re: [SCTP-Discussion] sctp_registerUdpCallback
Hi Andreas,
Will it be possible to control and use more than one association in
the sctplib instance in the sctpd?
If so, does that mean there is a new sctpd protocol wrapper for
datagrams exchanged between the user app and the sctpd to
differentiate between datagrams belonging to different associations?
Could I get a peak at the upcoming documentation for sctpd?
Michael
----- Original Message -----
From: "Andreas Jungmaier"
<ajung AT exp-math.uni-essen.de>
To:
<discussion AT sctp.de>;
"Michael Mueller"
<bhu5nji AT yahoo.com>
Sent: Thursday, November 15, 2001 2:13 PM
Subject: Re: [SCTP-Discussion] sctp_registerUdpCallback
: -----BEGIN PGP SIGNED MESSAGE-----
: Hash: SHA1
:
: Hello Michael,
:
: the sctpd demon program uses this functions, as it is a
: demon that handles SCTP and UDP input, and uses UDP to
: signal SCTP primitives between the (non-privileged) user
: application and the (SUID) demon (via localhost, as a
: simple IPC mechanism).
:
: I have integrated the latest version of that program along
: with some nice documentation and example programs (thanks
: to Sim Woon Chiat and colleagues) into the current sources,
: which I will release in a new version after some more testing
: probably mid next week.
:
: Regards,
: Andreas
:
: On Thursday, 15. November 2001 18:42, Michael Mueller wrote:
: > I am back to SCTP after a brief hiatus with TALI. I want to
use
: > UDP IPC to get 2 daemons exchanging datagrams. One daemon will
run
: > sctplib, while the other will source and sink datagrams.
: >
: > Has anyone used sctp_registerUdpCallback? Can you share details
of
: > how well it worked?
: >
: > Does anyone have source code using sctp_registerUdpCallback they
are
: > willing to share? My check of pre14 directories programs,
: > sctpd_programs, and socket_programs yielded no greps for
"UdpCall".
: >
: > If no source example is available, then I will submit mine back
to
: > the group if that is possible. Is that useful?
: >
: > Thanks,
: > Mike
: >
: > _______________________________________________
: > discussion mailing list
: >
discussion AT sctp.de
: >
http://www.sctp.de/mailman/listinfo/discussion
:
: - --
: - ----------------------------------------------------------------
--------
: 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
:
: iD8DBQE79BPmXAsLBNOCSsARAhYQAJwJEuHQMuRx5oB8oKM18wzaaUSBAACg4U8L
: 66+/f0+JGHXtmAtZ0pNA2Pg=
: =l68Q
: -----END PGP SIGNATURE-----
: _______________________________________________
: 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
Archive powered by MHonArc 2.6.19+.