[sctp-dev] Socket Options Issue

[Christopher Hegarty - Sun Microsystems Ireland]

Hi Bruce, Alan,

This is certainly an interesting issue, and surprising it wasn't noticed 
earlier. As was stated the retrieved SO_RCVBUF or SO_SNDBUF value is 
exactly twice the size of the value set.

[I must admit Bruce sent me a private mail about this issue a few days 
ago, so I have had a chance to investigate] ;-)

Running a simple native test shows that the problem is actually with the 
native LKSCTP stack, in fact there are actually functional tests for 
lksctp that test that the retrieved value is twice the value given!

I sent a mail to lksctp-developers [1], and they essentially said that 
the given value is doubled to provide a rough (very rough) estimate of 
the Socket Kernel Buffer overhead in the kernel per frame.

I'm not sure if we want to do anything at the java level to at least 
make these values match. As Alan said, the value set is only a hint to 
the OS so I don't think we should have functional tests that are relying 
on this. Actually, looking at the socket option tests we have in the 
test directory of OpenJDK the value set for these options is never 
directly compared to the value retrieved.

-Chris.

[1] 
http://sourceforge.net/mailarchive/forum.php?thread_name=20100112114607.GB23290%40hmsreliant.think-freely.org&forum_name=lksctp-developers

On 14/01/2010 15:23, Alan Bateman wrote:
> Bruce Buffam wrote:
>>
>> Hi Chris,
>>
>>  
>>
>> I am currently working on integrating the use of SCTP channels into 
>> Netty, an Open Source networking framework and I encountered an odd 
>> behaviour in setting/getting SO_RCVBUF or SO_SNDBUF.  Typically, I 
>> have some test code that sets one or both of these options and then 
>> immediately tries to retrieve the value.  If the retrieved value does 
>> not match the value that was set, the test code throws an exception.
>>
> FWIW, when you set these socket options then you are providing a "hint" 
> so you can't assume that the retrieved value will always be exactly the 
> value that you set.
> 
>>  
>>
>>  
>>
>> Here is some example code:
>>
>>  
>>
>>       @SuppressWarnings("restriction")
>>
>>       public void setReceiveBufferSize(int receiveBufferSize) {
>>
>>             // TODO Auto-generated method stub
>>
>>           
>>             try {
>>
>>                   
>> channel.setOption(SctpStandardSocketOption.SO_RCVBUF, receiveBufferSize);
>>
>>                   int temp = 
>> channel.getOption(SctpStandardSocketOption.SO_RCVBUF);
>>
>>                   if (temp != receiveBufferSize)
>>
>>                         throw new IOException("SO_RCVBUF not correctly 
>> set");
>>
>>             } catch (IOException e) {
>>
>>                   // TODO Auto-generated catch block
>>
>>                   e.printStackTrace();
>>
>>             }
>>
>>       }
>>
>>  
>>
>> My test case uses odd values like 9753, etc.  What I noticed, is that 
>> when I do the get, it consistently retrieves the value I set, 
>> multiplied by 2.
>>
>>
> Chris - this sounds like you might be missing the conversion/mapping 
> that is done by NET_SetSockOpt/NET_GetSocketOpt.
> 
> -Alan.
> 
> 
>