[sctp-dev] Send Buffer Free Space Query and Selector Info

[Danny]

Hi,

Does anybody know a way to find out how many free space (bytes) there 
are available in the send buffers. There seems to be no socket option to 
query that and i didn't find any method to query it either.
With that information it would be possible to avoid non-blocking send() 
calls that will fail with return value 0 due to insufficient space in 
the send buffer, and in the same process avoid all the preparative work 
that one does before calling send(), often involving memory allocations 
or buffer management. While this value would only be a tip application 
design, with proper synchronization means, could make sure then no two 
threads can send() and therefor this tip would be reliable because the 
returned value could not have decreased, at the most increased when more 
data would have been send by the provider in between the free space 
query and the application's send().

Furthermore i am looking for documentation or an answers to how the 
SCTPClient interacts with the Selector. More precisely i was wondering 
if the Selector triggers it's SEND and READ events on message boundaries 
or, if a fragmentation scenario is used, based on FULL fragments 
boundaries.

example: if i send : F1, F2, F3 fragments constituting one message on a 
single stream:
Will the SEND selection go off :
- after each F1,F2 and F3 fragment
   ---> when it is removed from the buffer
   ---> when it is effectively send on the wire
   ---> when it is acknowledged by the peer (=received & confirmed).
- OR after there is space (1 byte) or sufficient space (what is 
sufficient) to send more, which could possibly already happen if F1 is 
only partially send (due to thread swapping).

Will the READ selection (at the peer) go off :
- after F3 because it recombines at the lksctp/Solaris level and only 
then an event is send up resulting in a READ selection.
- OR after each F1,F2 and F3 fragment
- OR after there is sufficient data  (what is sufficient) to read, which 
could be after only part of F1 is available (due to thread swapping) 
probably resulting in auto-fragmentation by the receiver lksctp/Solaris 
or SCTP API.

This information would be helpful because i came to the conclusion that 
the SCTP contract that dissolves the "head-of-line" problem is kind of 
canceled out by reintroducing the problem at the Stream level.
If a large piece of data is send on a stream X (10Mb), and 50 small 
messages (1Kb) are available to be send on streams Y,Z then 
serialization occurs at the send() resulting in the 50 small once being 
blocked until the large one releases access to the send().
This as well in implementations that use thread pools, as in queue based 
implementations that use the Selector and certainly those using he 
blocking interface. If the Selector would trigger on fragment boundaries 
then it becomes possible to not only mix data from different streams, 
but in combination with the available free space in the send buffer, 
optimize it. Each SEND trigger would then become a driver for a round 
bobbin stream selector allowing  x Kb from that streams queue to be send.

In large networks handling a mix of multi-media and smaller application 
messages this would result in a huge boosts because systems depending on 
the smaller messages to perform work would not dry out when there is a 
lot of Multi-media traffic.


-Danny.