[sctp-dev] Socket Options Issues

[Danny]

Chris,

ok, in that case my concern has no more grounds.
In the light of the text you referred to this is a predictable behavior.

I have been reading the SCTP SO_RCVBUF documentation and it didn't 
extend to that detail.
My error, i should have remembered that there are standard sockets 
underneath it..

thx,
Danny

Christopher Hegarty - Sun Microsystems Ireland wrote:
> 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
>
>