Andre Garzia wrote:
Dar,
Sometimes I wonder why standards exists...
to keep standards writers in a job :-)
doing a simple googling on this topic I grooked that at least *BSD and
Windows2000 got settings for TCP Windows for receiving and for sending
data, I guess this must just be different buffer sizes ain't so?
Yes - but they're compatible - see my reply to Dar's email (summary -
transmit window is an additional constraint over and above the primary
config of recv window).
Using the sysctl command line tool one can probe this stuff or one can
risk his tcp/ip stack using commands like:
sysctl -w net.inet.tcp.recvspace= Desired value
sysctl -w net.inet.tcp.sendspace=Desired value
this examples are for NetBSD 2.0, and I really don't think one should
fiddle with this. One would gain nothing I think, if the client and
server got different buffer sizes no one will gain by increasing it's
own size right? and the chances of this misbehaving is just too big....
Remember that many senders - in particular, servers capable of high
performance - have already had their parameters tweaked, and are limited
only by what you can accept - i.e. your receive window.
Probably not an issue at 1Mb or below - but when you get above that -
especially in the presence of jitter (variable delay) - you need more
than 32k window to allow high-speed but distant servers to get close to
filling that pipe to you.
So it's worth setting the receive window in many cases. If you're a
server and have memory bandwidth to handle it, it's worth setting the
transmit window, in case you are contacted by receivers able to utilize
bigger receive windows.
And the chances of this misbehaving are pretty small - TCP is designed
to flourish (not merely survive) in the presence of many mismatched
configurations...
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.3.0 - Release Date: 30/05/2005
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
