[sctp-dev] SCTP Message fragmentation

[Danny]

Chris,

Your online replies answer my question completely. I have another 
question related to the topic of fragmentation and the way 
SendFailureNotification works.
I will start this as a separate topic in order to keep the topics to the 
point.

Thanks,
Danny

Christopher Hegarty - Sun Microsystems Ireland wrote:
> 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
>>
>
>