[sctp-dev] SCTP Message fragmentation

[Danny]

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

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

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