Strange behaviour with sockets, SetSockOpt and Solaris 10
in [Solaris]
|
From: Richard B. Gilbert on 10 Apr 2010 16:50 Chris Ridd wrote: > On 2010-04-10 20:42:37 +0100, Drizzt said: > >> Ok, maybe my English writing skills are not so good, but after the >> sentence >> "so it calls SetSockOpt for changing the SO_SNDBUF; the function >> return 0" >> why someone should doubt if we are calling SetSockOpt and if we are >> checking the return status of the call itself? > > I think that's mostly because C function names are case-sensitive, so > SetSockOpt is not the same as setsockopt. Are there two functions with similar names, the difference being that one capitalizes S,S, and O and the other does not?
From: Ian Collins on 10 Apr 2010 17:59
On 04/10/10 05:23 AM, Rick Jones wrote: > Ian Collins<ian-news(a)hotmail.com> wrote: >> On 04/ 9/10 11:21 PM, Drizzt wrote: >>> I all. >>> >>> We are having a huge problem trying to move from Solaris 9 to >>> Solaris 10, specifically with the SetSockOpt function. One of our >>> processes need a socket with a writing buffer of about 700.000 >>> bytes, so it calls SetSockOpt for changing the SO_SNDBUF to >>> 700.000; the function return 0 (no err), but successive calls to >>> GetSockOpt to retrieve the SO_SNDBUF returns that the buffer it's >>> still at its default value (64k) and the app hang just after few >>> minutes on write operations over the socket. >>> >> I assume you are using setsockopt, not some local function? > > We should probably also ask if the return status of the call is being > checked. > >> You will have to raise the maximum value for the driver before these >> changes will work. To do that, use ndd: > >> ndd -set /dev/tcp tcp_xmit_hiwat 700000 > > Does that actually set a maximum one can request via setsockopt()??? > I do run netperf under Solaris from time to time and do not recall > ever having to alter tcp_xmit_hiwat to allow me to have successful > setsockopt() calls for larger buffer sizes. > >> http://docs.sun.com/app/docs/doc/817-0404/chapter4-31?a=view > > Suggests that perhaps you meant tcp_max_buf instead. It also suggests > the default value for tcp_max_buf is 1048576 bytes. Yes you are right Rick, got I got the the wrong one for individual connections. I just ran a quick test and attempting to set a SO_SNDBUF to > 1048576 bytes fails with "No buffer space available". It works after increasing tcp_max_buf. -- Ian Collins |