FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafone.com]
> Sent: November 25, 2003 8:52 AM
> 
> > It's a very interesting option! However I don't know all 
> > disavantage it can take. Anyone know a way to "flush" socket 
> > correctly? By the way... attached a patch to enable TCP_NODELAY.
> > 
> http://www.unixguide.net/network/socketfaq/2.11.shtml
> http://freebooks.by.ru/view/SambaIn24h/ch23.htm
> 
> Perhaps it's really a good idea... however I still don't 
> understand why there isn't a flush call for socket :(

AIUI there's no flush call for a socket because the receiver isn't passive.
A disk is always prepared to receive data, but a socket peer may not be.
The best you can do is post your data, and let the network do its job.  

I'd like to understand better what's going on.  Craig Jackson, can you help
us out here?  

What puzzles me: TCP_NODELAY involves flushing small packets, instead of
bundling them together.  Examples given are mouse data or vi sessions.  But
TDS doesn't involve small bits of data.  Even a small query has a header and
its TDS packet.  

It is possible that a query may not quite fit in a packet.  Say, with all
overhead included, we had a 513-byte query, and we write our 512 byte packet
(with a "more data" flag).  Then we write our last byte, including its
8-byte TDS header, of course.  Will those 9 bytes stay parked in our local
network buffers for some non-trivial time?  Can that really account for your
statistics?  

If I understand correctly, the remnant packet will wait in the client's
buffer until its predecessor has been acknowledged i.e, until the window is
wide open.  I guess on an Ethernet the delay isn't noticeable, and
database-style client/server interactions make somewhat atypical use of the
network.  It's hard for me to believe that's normally how things work, that
there's no way to say, "OK, I'm done.  It's his turn to talk now."  

If I've got the above all correct, there are only two partitial solutions:

1.  Ideally (I think), we would be able to set the TCP PUSH flag to indicate
we're done.  That would cause the TCP stack to transmit the not-full packet
immediately, provided the window is open, without waiting for
acknowledgement of the prior packet.  Many (most?) implementations provide
no interface to set the PUSH flag, however; according to the RFC, it's
optional.  

2.  Setting TCP_NODELAY, to force every packet out ASAP after write(2)
completes.  Again, though, not every setsockopt(2) supports this option.  

Which makes your patch look pretty good, for those implementations that
support it.  

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.