>> I want to send to the FTP server blocks no bigger than <n> bytes
>> (in case the FTP server has a slow line), does libcurl do it
>> automatically?
 
> As Daniel mentioned, I don't think setting the TCP stack's send buf
> size will really accomplish what you want to achieve. Setting the
> sendbuf doesn't force the TCP implementation to send only certain
> size chunks onto the wire at any one time, it is just a suggestion
> for how much the TCP stack will buffer in its pending send queue,
> and even there, it is only a suggestion to the stack, it does not
> need to abide by it on many implementations.
 
TCP has to maintain a reference to sent, but unACKnowledged data until
the ACK arrives. How much data a sending TCP can reference is
controlled by the likes of SO_SNDBUF. So, if one were to set SO_SNDBUF
to 1024 bytes, the sending TCP would only be able to track 1024 bytes
of data out on the network, which means you could be reasonably
assured that TCP would not send anthing larger than a 1024 byte TCP
segment (TCP "packet" == segment, UDP "packet" == datagram) at any one
time.
 
Some TCP stacks will allow a setsockopt() call with the TCP_MAXSEG
option, and that may allow a smaller-than-negotiated MSS (Maximum
Segment Size) to be used. However, that tends to require the caller to
be root, and it is _far_ from universal across platforms.
 
One could I suppose setup a host route with a PathMTU value such that
TCP negotiated a smaller MSS - that too requires root to manipulate
the routing tables.
 
Even then, it would not alter the _rate_ at which TCP could transfer
data, since the maximum rate of a TCP connectoin is bounded by (maong
other things) the Window size (W) divided by the Round Trip Time (RTT)
- ie W/RTT. The smaller segment size would only make the transfer
_less_ efficient. The ratio of data to data+headers would be worse,
so less efficient use of the slow link would result.
 
It _might_ make a simultaneous telnet or other interactive session
appear to be a bit more responsive, but that sort of thing is perhaps
best dealt with with some sort of QoS mechanism. In those cases, one
would want to make sure that libcurl set the options for throughput
but ont low delay on the FTP data connection (and low delay on the FTP
control connection), and that the other app set TOS values
apropriately and that the router in front of the slow link did the
right hting with those values.
 
rick jones

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-10-18