[sctp-dev] Send Buffer Free Space Query and Selector Info
danny at tower.telenet.be
Thu Feb 11 06:22:50 PST 2010
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
example: if i send : F1, F2, F3 fragments constituting one message on a
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.
More information about the sctp-dev