SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] Sctplib on Android


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

On 27 Feb 2014, at 15:57, Thomas Dreibholz
<dreibh AT iem.uni-due.de>
wrote:

> 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.
In usrsctp we made the local encapsulation port configurable. That way you
can run multiple instances (with different local encapsulation ports) on
one machine. Even a kernel stack and a userland stack...

Avoiding root privileges is one of the reasons to use UDP encapsulation.
So implementing UDP encapsulation using raw sockets is sub-optimal...

Best regards
Michael
>
>
> 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
> =======================================================================





Archive powered by MHonArc 2.6.19+.

Top of page