lkml.org 
[lkml]   [2000]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: socket: setting SO_SNDBUF
Date
From
In article <E12phTj-0003lb-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> because I would expect following behaviour:
>>
>> err = getsockopt(s, SOL_SOCKET, SO_SNDBUF, &res1, &len);
>> err = setsockopt(s, SOL_SOCKET, SO_SNDBUF, &res1, len);
>> err = getsockopt(s, SOL_SOCKET, SO_SNDBUF, &res2, &len);
>>
>> after that sequence, res1 should be == res2 !
>>
>> Am I totally wrong?
>
> Nothing in the standards says anything about that being true
>

If you don't attach some semantics to SO_SNDBUF even if there are no
standards, you basically make it a completely useless call, since nobody
can know what value you are supposed to give.

I can only find it reasonable that it sets an order of magnitude for the
buffersize, that this may not succeed, but if you 'get' it again, you have
a reasonable approximation of how much space you actually got, using the
same measurement units as the set.

If you don't do this, what were you planning to put in the man page for
SO_SNDBUF ?

If it was a COMPLETELY meaningless number, why did you bother fudging it
on set ? (yes, I know, existing programs. Don't they deserve the same
courtesy for get ?)

So why not end this recuring thread by just fudging the get by the same
factor as set ? It still remains an ill-defined number, but at least
there will be consistency between in and out.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.058 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site