[sctp-dev] Socket Options Issues

[Christopher Hegarty - Sun Microsystems Ireland]

Hi Danny,

I do understand your concern, but I think doubling the set value for 
these options, SO_RCVBUF & SO_SNDBUF, is standard in the Linux socket 
interface ( I just forgot about it when implementing the SCTP API! ). So 
I don't think the SCTP provider will impact this. The provider is simply 
a thin layer on top of the kernel implementation.

 From 'man -a 7 socket':

   SO_RCVBUF
     Sets or gets the maximum socket receive buffer in bytes. The kernel
     doubles  this  value  (to  allow space  for  bookkeeping
     overhead) when  it  is  set  using setsockopt(2), and this doubled
     value is returned by getsockopt(2). .....

-Chris.


On 06/02/2010 09:53, Danny wrote:
> Hi Chris, Bruce and Alan.
>
> I just subscribed to this list and therefore had to make a new subjects
> in order to add to the conversation about the Send/Receive Buffer size
> settings.
>
> I had the exact same problem and have seen the solution proposed by
> Chris to solve it in b81. However i am a little worried about the
> dividing by 2 solution.
>
>
> I use lksctp too on Fedora and indeed they double the size today. But
> what if they change strategy or if another protocol provider is used
> that does not double the size.
> I have build a work-around in may class constructors that has a solution
> that may be robust over time and that i would like to share (possibly
> you are already doing this but that's behind my knowledge).
>
> I retrieve the buffer size (for both send and receive buffers) and back
> them up in a variable. I then set the size to a well known value (eg
> 4096) and retrieve it back.
> I then initialize a variable with the result of the division of the
> retrieved size divided by the well know set size. I call that my buffer
> multiplier.
> Finally i a then set the initial buffer size back from my backup
> variables multiplied with the buffer multipliers (which for lksctp are
> 0.5 today).
> The multiplier can now be used to correct the retrieved buffer sizes by
> a simple multiplification.
>
> The back-draw of my solution is that i have no means to make the change
> inside getOption() but you do.
>
> I do not agree that in SCTP this buffer size should only be a hint. I
> can understand it for TCP but in SCTP one must be able to optimize
> fragmentation.
> Consistency is important, the returned value must be reliable to
> indicate how many bytes the buffer can hold, while it is less important
> to know that a buffer
> from, let's say, 2048 bytes approximately consumes 4096 bytes of memory.
> By adding to the documentation that programmers should keep in mind that
> the
> buffer size must roughly be multiplied by 2 to get the consumed memory
> they should be all set.
>
> It was during the implementation of SCTP fragmentation that i discovered
> the buffer size problem in my case. In order to stay with the topic i
> will post a second post about this
> and a minor problem with using SCTP with the Selector in separate post's.
>
> Greetz,
> Danny