SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] SCTP implementation


Chronological Thread 
  • From: "La Monte Henry Piggy Yarroll" <piggy AT baqaqi.chi.il.us>
  • To: discussion AT sctp.de
  • Subject: Re: [SCTP-Discussion] SCTP implementation
  • Date: Tue Mar 13 13:06:00 2001
  • List-id: SCTP Discussions <discussion.sctp.de>

Andreas Jungmaier
<ajung AT exp-math.uni-essen.de>
writes:
> On Monday, 12. March 2001 15:32, Yiwen Jiang wrote:
> > > Before you start writing a Diameter server, I suggest you get
> > > familiar with the SCTP :-)
> >
> > I would like to do that... I only started working on Diameter a week
> > ago!-(
> >
> > I don't think one needed to know the fine details of TCP before one uses
> > it
> > to implement a daemon... From your comment, it seems that one needs to
> > understand the nitty gritty of SCTP before doing Diameter then? What would
> > the reason behind this? Or did I misunderstood?
>
> Well SCTP is a transport protocol, so it essentially does similar
> things as TCP. However, there is (not yet) a socket API, so each
> implementation has sort of its own API (however most complete
> implemetations will adhere more or less to section 10 of RFC 2960)

I would like to mention that there IS a draft API,
draft-stewart-sctpsocket-sigtran-02.txt.

The proposed API provides two alternative views.

One view provides a TCP-style interface and is specifically designed
to make it easy to port TCP applications to SCTP.

The other view provides a UDP-style interface. The UDP-style
interface is designed with extremely high traffic applications in
mind. It allows a single fd for hundreds of associations, and also
allows you to peel off a single association into its own fd. It is
very similar to current UDP, but there is an extra cmsghdr structure
which carries SCTP-specific information.

Both views allow optional notifications of SCTP-related events. The
format of these events will probably change at least one more time.

If I can get the funding, I may be implementing a Java API by
mid-summer. In that case, I'm very likely to borrow heavily from
Andreas' and Michael's API. I really like the callback model, but
that is very difficult to implement at the kernel level.




Archive powered by MHonArc 2.6.19+.

Top of page