Chronological Thread 

< Chronological >      < Thread >

---

On 20 Oct 2002 17:21:46 -0000, "Garima gupta"
<garima_g01 AT rediffmail.com>
wrote
:
> Hi,
> I have no problem in reinstalling the linux freshly because i
> have already messed up with both lksctp implementation and
> www.sctp.de implementation to core and iam not scared to
> experiment.
>
> Out of the two options you suggested i prefer the www.sctp.de
> implementation ,but as i have to code a sctp client/server
> application and test its main benifit -"multihoming", i will need
> to run more then one process which will use the sctplib and as you
> have pointed out that only one process can be actively running the
> sctplib on a host and i have only one machine to work on i am
> forced to choose the lksctp implementation.

There IS an SCTP server process available as part of the sctp.de
implementation, which will let you use multiple processes with that
implementation.

> But still iam not confident with lksctp and the reason is that i
> think lksctp don't have good support( I have posted my problem on
> the mailing list but there is no reply yet) and i wanted to
> compare sctp's multihoming benifits with tcp, and as u have told
> me that lksctp code has only the UDP-style socket API implemented
> at this point.

Your posting to lksctp-developers is only 12 hours old. It IS Sunday
afternoon on this half of the planet... You're asking a LOT from free
technical support. You WILL see some kind response within a day or
two.

True, LKSCTP only has the UDP-style socket API, but it is not at all
difficult to change TCP code to SCTP UDP-style code. Mainly, you need
to remove the listen/accept loop from your TCP code. You only need to
call listen() once on the UDP-style socket, and then you just send and
receive. You may need to change over to using sendmsg() and recvmsg()
in order to get access to all features.

Your questions to the lksctp list are very hard to understand. It
seems you are having trouble with one of the download kits. I
generally recommend that people work with the complete CVS repository,
as we have very strict rules on what may be committed. Instructions
for CVS are at: http://sourceforge.net/cvs/?group_id=26529

Your other questions seem to involve problems with building the
implementation. The instructions at
http://lksctp.sourceforge.net/sctp_howto.html are very complete. If
those are unclear, we'd like to know at what step you got lost.

The LKSCTP distribution includes a fairly complete sample program,
sctp_darn. At http://lksctp.sourceforge.net/testing.html you will
find more details about that program.

> ps: I am root on one machine (my personal) and normal user account
> on my university's linux machines.
>
> thanks
>
> Garima
>
>
> On Sun, 20 Oct 2002 Phillip Conrad wrote :
> >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).
> >
> >
> >
> >_______________________________________________
> >discussion mailing list
> >discussion AT sctp.de
> >http://www.sctp.de/mailman/listinfo/discussion
>
> __________________________________________________________
> Give your Company an email address like
> ravi @ ravi-exports.com. Sign up for Rediffmail Pro today!
> Know more. http://www.rediffmailpro.com/signup/
>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

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