Chronological Thread 

< Chronological >      < Thread >

---

At 12:47 PM 10/20/2002 +0000, Garima gupta wrote:
>Hi,
> Thanks Michael for you help, As first I installed both the sctp
>api implementation and the sctp socket implemention and later sctp
>kernel implementation from sourceforge Iam now totally confused,

Your confusion is understandable; until SCTP support is a standard part of OS
distributions, it will be a bit tricky to work with SCTP. This is a normal
part of the "growing pains" of any new technology.

See my comments below...

>my doubt is this that
>can anyone tell me how is lksctped implemented kernel different
> from normal kernel on which sctp api and sctp socket
>implementation is installed, i mean, how are two different when
>one wants to compile and run some applications on two.
>And will it make trouble when one installs both the
>implementations and lksctp like in my case.

Just my opinion.. others may differ....

Since you seem to be just starting out with SCTP programming, you would
probably be best served by just starting over with a fresh linux install (if
this is feasible) and then choosing EITHER to download the www.sctp.de code,
OR the lksctp code, but not both.

There is probably a way to get the two to co-exist peacefully on the same
machine, and if fact it may even be trivial. I have some idea of how to do
it, but I hesitate to get into it, because getting them to live peacefully
together is really an advanced topic, and no-one is likely to be able to be
able to give you the kind of step-by-step instruction that you would need (at
this stage in your knowledge of the two implementations) to make that work.
This is why I suggest a clean re-install; you are more likely to get useful
help from folks on the list if work with just one implementation at a time.
:-)

But if this is not feasible here's a quick suggestion, with the stipulation
that I will not give you any further explanation (maybe someone else on the
list will help, but as far as I'm concerned, you'll just have to sink or swim
with this, and figure out what it means on your own!)

For the socket API of the www.sctp.de implemenation, the socket calls are
implemented with names such as ext_socket, ext_listen, ext_accept, etc.
Somewhere in one of the header files, there is a #define symbol where it
checks to see if you have a kernel sctp implemented (that symbol is called
something like "HAVE_INKERNEL_SCTP") If that symbol is defined, the
www.sctp.de code tries to map ext_socket to socket, ext_accept to accept,
etc. If that symbol is not defined, then your program will likely ignore
the lksctp kernel mods, even if they are installed.

But that is just a guess... it may or may not work, and from here you are on
your own.

I still think a clean install of one or the other would best. Which should
you choose?
Why choose one over the other? These are just some top of head suggestions:

I would choose the www.sctp.de implementation if you want more of the
features of the sockets API to be implemented (for example, to use the
TCP-style model of the sockets API), and you are willing to use a
"user-level" implementation. My understanding is that the lksctp code has
only the UDP-style socket API implemented at this point. Although I
haven't seen any performance evaluations, one might expect a "user land"
implementation to be slower than an in-kernel implementation.

Also, there are some limitations of the www.sctp.de implementation: only one
process can be actively running the sctplib on a host (though that process
can have multiple associations) unless you turn off "out of the blue"
processing, and user processes must be run with "root privlege".

(Out of the blue processing provides an ABORT response if a process tries to
establish an associaton to your host, and there is no process listening for
that association. Root is necessary in order to run )

Choose the lksctp code if you want to run on linux, and any of the following
are important to you:
(1) an in-kernel implementation.
(2) being able to run user processes without root privlege
(3) running multiple processes on the same host with OOTB enabled

and you are willing to work with only the UDP model of the SCTP sockets API.

Full disclosure: I've worked with the www.sctp.de quite a bit, but only know
"about" the lksctp code from conversations with the developers of that code,
so my information is only as accurate as my understanding of what they told
me.


Hope this helps!
Phill Conrad

PS: By the way, if you are willing to use FreeBSD instead of Linux, there is
another option: an in-kernel implementation for FreeBSD. See
http://sctp.chicago.il.us for details. Essentially, you download a snapshot
of the Kame stack from www.kame.net, apply any patches from
http://sctp.chicago.il.us (this is sometimes necessary, and sometimes not,
depending on the release cycle) build the Kame kernel per the Kame
instructions (but enabling the SCTP options in the config file when you are
at that step.) This implementation has the full socket API implemented (or
if not full, then very nearly so), and provides SCTP as a "first class
citizen" transport protocol ( all the same rights, privileges and limitations
that apply to TCP and UDP).

---

• [SCTP-Discussion] sctp impl and lksctp, Garima gupta, 10/20/2002
  • Re: [SCTP-Discussion] sctp impl and lksctp, Phillip Conrad, 10/20/2002
  • Re: [SCTP-Discussion] sctp impl and lksctp, Michael Tüxen, 10/21/2002
  • <Possible follow-up(s)>
  • Re: Re: [SCTP-Discussion] sctp impl and lksctp, Garima gupta, 10/20/2002
    • Re: [SCTP-Discussion] sctp impl and lksctp, La Monte Henry Piggy Yarroll, 10/21/2002
      • Re: [SCTP-Discussion] sctp impl and lksctp, Phillip Conrad, 10/21/2002

---

Archive powered by MHonArc 2.6.19+.