SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] Sctplib on Android


Chronological Thread 
  • From: Thomas Dreibholz <dreibh AT iem.uni-due.de>
  • To: Michael Tuexen <Michael.Tuexen AT micmac.franken.de>
  • Cc: "sctp-discussion AT sctp.de" <sctp-discussion AT sctp.de>
  • Subject: Re: [SCTP-Discussion] Sctplib on Android
  • Date: Thu, 27 Feb 2014 15:57:06 +0100
  • List-archive: <http://lists.franken.de/pipermail/sctp-discussion>
  • List-id: SCTP Discussions <sctp-discussion.sctp.de>

Torsdag 27. februar 2014 15.26.06 skrev Michael Tuexen:
> On 27 Feb 2014, at 14:12, Dag Ove
> <daggy2k AT hotmail.com>
> wrote:
> > In the SCTP-API of sctplib:
> > 6.4 ULP-to-SCTP
> > 6.4.1. sctp_initLibrary()
> > "This function will open raw sockets for capturing SCTP packets (IPv4 and
> > if possible, IPv6 too) from the network and initialize the timer list. It
> > needs to be called before any other functions of the libsctp-library are
> > called"
> >
> > I interpret the above line that function sctp_library() needs to be called
> > regardless if using SCTP/IP or SCTP/UDP. Is it possible that if I only
> > intend to use SCTP/UDP I dont need to call sctp_initLibrary() ?
> No, you need to initialise the library.
>
> > The context I want to use SCTP/UDP is as an example protocol for comparing
> > it to HTTP/TCP and plain UDP when exchanging SOAP messages/XML data with
> > a Web service server, so I simply want to use in a peer-to-peer system
> > between Android and a java server.
> OK.
>
> > It had a look at usrsctp, but I had more trouble compiling the native C
> > for Android, some classes/headers were missing (ifaddrs.h, umem.h,
> > pthread.h). I am not very familiar with freeBSD.
> I haven't build the library on a plain Android system, but you might want to
> the build process of Firefox and the corresponding files:
> http://mxr.mozilla.org/mozilla-central/source/netwerk/sctp/src/
>
> > SCTPLIB was easier to compile and install on Android, but the problem
> > arised when" sctp_initLibrary()" calls "adl_init_adaptation_layer()",
> > which in turn calls "adl_open_sctp_socket()". I don't understand why the
> > function "adl_open_sctp_socket()" in adaptation.c tries to open a raw
> > socket even if SCTP_OVER_UDP is set (ref lines 571-585 in
> > https://github.com/dreibh/sctplib/blob/master/sctplib/sctp/adaptation.c)
> >
> > I this is not an implementation error, I would be very interrested in what
> > functions to use to enable SCTP_over_UDP.
> OK, I looked at the code. It is implemented using raw sockets. This could be
> changed for UDP encapsulation to not use raw sockets in the same way as it
> is done n the usrsctp code. I don't have to time to do that, maybe Thomas
> has. Not sure. It is not very difficult...

The reason for using raw sockets is to have the possibility to run multiple
instances of userland SCTP on the same machine. OOTB handling is turned off,
so
each instance only responds to packets with the right destination port
number.
So, if you ensure that all instances use different port numbers, this makes
it
easy to test or use SCTP communication on the same machine.

It should not be difficult to adapt the behaviour, but then you can use only
one
sctplib instance per machine.


There is, somewhere, an experimental code for an sctplib daemon by Andreas
Jungmaier. This would solve the problem (one SCTP userland daemon, used by
multiple SCTP applications attached via Unix sockets), but this code has
never
been updated (and I have never tested it).

--
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

=======================================================================
Thomas Dreibholz

Simula Research Laboratory
Simula Innovation AS, Network Systems Group
Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway
Mailing address: P.O.Box 134, 1325 Lysaker, Norway
-----------------------------------------------------------------------
E-Mail:
dreibh AT simula.no
Homepage: http://simula.no/people/dreibh
=======================================================================

Attachment: signature.asc
Description: This is a digitally signed message part.




Archive powered by MHonArc 2.6.19+.

Top of page