On Thu, 7 Sep 2000, Yaron Zabary wrote:
1. Why does TCP aggregate the first few records, and then "settle
down" and behave as expected?
Probably Nagle (take a look at RFC 896 'the small packet problem'). Try
to disable Nagle on the senders (not sure this is possible).
disabling NAGLE is
1. It's not Nagle
2. Keren is right - Mostly. 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. After sending off my original query, I
went for a long walk, and hit on the
answer, which I just finished
so just get the fourth (fifth, actualy) of Stevens: Unix socket programing
.
Dani
On Thu, 7 Sep 2000, Daniel Feiglin wrote:
1. It's not Nagle
2. Keren is right - Mostly. I did take care to have my client flush its output
buffer after each write, so the server
should have picked the same
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.
Bear in mind that this solution has the
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
This programming problebm is not specific to Linux; it can be reproduced under Unix
(e.g Solaris).
Here is the scenario: I have a C++ server (a sort of logger, a bit like syslog) and
many Java clients.
Each Java client sends the server a text header record which I'll describe in a
moment,
On Wed, 6 Sep 2000, Daniel Feiglin wrote:
[... lots of data deleted...]
When a client comes up, for some reason orother, the header and the
first first few log records are aggregated by TCP, and appear on
select() as a single read(). All subsequent client writes are picked up
correctly. I
