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 :-)

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

Ian Collins <ian-news@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...

"Rick Jones" <rick.jones2@hp.com> ha scritto nel messaggio 
news:hpnnpt$2fi$1@usenet01.boi.hp.com...
> Ian Collins <ian-news@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?

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

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?

On 04/10/10 05:23 AM, Rick Jones wrote:
> Ian Collins<ian-news@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