On Thu, 7 Sep 2000, Daniel Feiglin wrote:
> 1. It's not Nagle
what do you base this claim on?
> 2. Keren is right - Mostly.
keren (or rather - guy) is right - fully. what you implemented below is a
workaround that probably suited your specific requirements specifically.
however, more comments below:
> I did take care to have my client flush its output buffer after each
> write, so the server
> should have picked the same number of reads.
not true at all. you have no control on buffering done at the receiving
machine, network slowness, etc. there is _NO_ gurantee that packets
segments sent in seperate system call invocations on the sending side
won't be read by a single system call invocation on the receiving side.
and there is _no_ gurantee that a packet of data is sent fully - it may
stil be split into several segments and thus arrive in seperate chunks to
the receiving machine.
btw, as i understand, after you opened the og file, you just write data
sequentially into the log file, without any kind of formatting (e.g.
breaking long lines, or inserting new line chars - you assume the new line
chars are part of the packet data?).
> After sending off my original query, I went for a long walk, and hit on
> the answer, which I just finished implementing. It's this:
> The listener thread, upon registering a client in the user table, allows
> the mux read thread to start collecting data.
> Despite the flush, and despite my pacing the client messages 1/2 a
> second apart, the header and the first few records
> get picked up. I grab the header and open the output file. All
> subsequent stuff goes to the output log file - apart from
> the first few entries. The oddball thing, is thereafter there is no
> apparent buffering of client data.
perhaps because the data later on is sent in smaller chunks, and perhaps
due to some implementatin details of your TCP stack on one or both sides.
in any case - this is not odd at all. this is how TCP might work.
> The solution is quite simple: Have the Java client do a (blocking) read
> (of say, one byte) on the socket after sending
> the header. Have the server sent a single "sync" byte to the client
> immediately after opening the log file. And all works just fine.
one question: when you read the header - do you check the return value or
'read', and make sure you've read a complete header, and only part of the
header? if not, your application might break under some circumstances. if
your application might be deployed over a WAN, or on busy machines, for
instance, this could expose bugs that testing on a LAN and non-busy
mahcines wouldn't expose.
> Apropos of reading a good book on TCP "kishkes" - I have Steven's 3 "Protocol"
>volumes: You need a year's
> sabbatical from work to read them ...
without reading about the details of TCP/IP, you'd face odd bugs and
problems in your code. if you only write a singel TCP application in your
career - that's one thing. if you intend to write more then one - reading
about the protocol is a good thing to do. and you don't have to read all 3
stevens' books. begin with an explanation about the protocol itself. a few
hundread pages of douglas comer (probably 200-300 pages) would do.
guy
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
