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