[sctp-dev] SCTP Message fragmentation

[Christopher Hegarty - Sun Microsystems Ireland]

Danny,

comments inline...

On 06/02/2010 11:47, Danny wrote:
> Hi,
>
> I have implemented message fragmentation and needed to implement a
> work-around because the SCTP_EXPLICIT_COMPLETE did throw when set with
> the setOption().
> At first i thought that the lkscp lib didn't provide the feature and
> assumed that fitted within the SCTP API's documentation stating that the
> availability of the feature was provider specific.
>
> While fragmentation interleaved on different streams
> (SCTP_DISABLE_FRAGMENTS false and SCTP_FRAGMENT_INTERLEAVE 2) works fine

These two options are supported on lksctp since the lksctp stack 
supports there native equivalents.

> when used with a the work-around passing the isComplete as a robbed-bit
> from the payloadProtocolID, it is however only working between peers
> that have that same workaround implemented. Therefore a started looking

Both your client and server determine whether the message is complete, 
or not, by looking at the payloadProtocolID? Interesting... and a very 
ingenious workaround!

> at the lksctp stite.
>
> This site, in it's feature list, refers to the "Socket API Extensons for
> SCTP", draft-ietf-tsvwg-sctpsocket-15.txt for it's implementation support.
> This document contains the SCTP_EXPLICIT_EOR (End of record) support in
> section 7.1.30 which is the SCTP protocol equivalent of the SCTP API's
> SCTP_EXPLICIT_COMPLETE.

Here is a link to a thread where I asked about lksctp SCTP_EXPLICIT_EOR:
 
http://sourceforge.net/mailarchive/message.php?msg_name=48C1369B.7060800%40hp.com

 From my experience implementers of the socket API extensions are 
reluctant to do much more work without the API being finalized. For the 
past two years of so now, I've been hearing that this API is close to 
being finalized, but unfortunately it is still in draft form.

> Could someone confirm if :
> - the Feuture not Supported exception throw is not due to a mapping
> problem between SCTP_EXPLICIT_COMPLETE to SCTP_EXPLICIT_EOR in the API.

lksctp currently does not support SCTP_EXPLICIT_EOR. Yes, 
SCTP_EXPLICIT_COMPLETE maps directly on to SCTP_EXPLICIT_EOR.

> - in case the feature isn't supported yet, if and when it could be (i
> realise this is lksctp related but some of you may have contacts).

I don't know when SCTP_EXPLICIT_EOR will be supported by lksctp, but I 
bet it is dependent on the socket API extensions being finalized.

-Chris.

> A tried taking control back by clearing the isComplete flag in the
> MessageInfo structure before handing it over to the send() method, in
> this way simulating the explicit complete behavior myself by only
> leaving the falg set for the last fragment, but the send() (of the API
> or lksctp) turns it back on (set it to true), reason why it arrives at
> the remote peer as 'true' all the time and as a consequence i need to
> stick to the work-around which has it's back-draws.
>
> My code does automatically switch from the work-around to the usage of
> the standard MessageInfo.isComplete() when setting socket option
> SCTP_EXPLICIT_COMPLETE doesn't throw but as said the work-around depends
> on similar work-around support in the remote peer. Adding EXPLICIT
> COMPLETE/EOR support at first sight looks like a simple thing.
>
> Any information on this would help.
>
> Greetz,
> Danny
>