[sctp-dev] SCTP Message fragmentation
danny at tower.telenet.be
Sat Feb 6 03:47:59 PST 2010
I have implemented message fragmentation and needed to implement a
work-around because the SCTP_EXPLICIT_COMPLETE did throw when set with
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
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.
More information about the sctp-dev