Strange behaviour with sockets, SetSockOpt and Solaris 10
in [Solaris]
|
From: Drizzt on 9 Apr 2010 07:21 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. Designing issues aside (well, it's not a really optimized system, but we inherited it), the thing that it's making my collegues go crazy is that the same exact code, run on Solaris 9, works like a charm. And, after SetSockOpt, calling GetSockOpt get the value we expected. Uh, and the Solaris 10 machine it's patched up to the last patch...anyone can help? Thank you all :-)
From: Ian Collins on 9 Apr 2010 07:50 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? 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 ndd -get /dev/tcp \? will list all the driver tunables. They are documented here: http://docs.sun.com/app/docs/doc/817-0404/chapter4-31?a=view -- Ian Collins
From: Rick Jones on 9 Apr 2010 13:23 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. rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Drizzt on 10 Apr 2010 15:42 "Rick Jones" <rick.jones2(a)hp.com> ha scritto nel messaggio news:hpnnpt$2fi$1(a)usenet01.boi.hp.com... > 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. 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?
From: Chris Ridd on 10 Apr 2010 16:36
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. -- Chris |