Missing bytes in TCP connection from Windows to Linux

I'm running redhat 9.0 and windows 2000 professional. From my linux
box I have a client that sends and receives data via a socket to a
windows server application. The server writes many small packets (~30
packets, 1-10 bytes) back to the client as an ack. The server
application is not ours and we can't change it.

In the linux client, I continue to call recv to pull the entire
message off the socket. There are times when I don't receive all of
the bytes that the server application says it sent. tcpdump on the
linux box confirms that the data never arrives.

We are not sure if one or more packets is being dumped via overflow on
either the Windows box or the linux box. Attached is a part of the
strace. Any ideas?

Are there any windows or linux kernel level settings that may need to
be modified?

Many Thanks.


send(4, "\vMSH|^~\\&|HL7 SEND|TPMG-SSC|EASY"..., 347, 0) = 347
time([1063863694]) = 1063863694
write(3, "20030917-22:41:34 Info: sendMes"..., 54) = 54
select(5, [4], NULL, NULL, {5, 0}) = 1 (in [4], left {4, 850000})
recv(4, "\vMSH", 4096, 0) = 4
select(5, [4], NULL, NULL, {5, 0}) = 0 (Timeout)
recv(4, 0x8067930, 4096, 0) = -1 EAGAIN (Resource
temporarily unavailable)

Chris B. wrote:
> I'm running redhat 9.0 and windows 2000 professional. From my linux
> box I have a client that sends and receives data via a socket to a
> windows server application. The server writes many small packets (~30
> packets, 1-10 bytes) back to the client as an ack. The server
> application is not ours and we can't change it.
>
> In the linux client, I continue to call recv to pull the entire
> message off the socket. There are times when I don't receive all of
> the bytes that the server application says it sent. tcpdump on the
> linux box confirms that the data never arrives.
>
> We are not sure if one or more packets is being dumped via overflow on
> either the Windows box or the linux box. Attached is a part of the
> strace. Any ideas?
>
> Are there any windows or linux kernel level settings that may need to
> be modified?
>
> Many Thanks.
>
>
> send(4, "\vMSH|^~\\&|HL7 SEND|TPMG-SSC|EASY"..., 347, 0) = 347
> time([1063863694]) = 1063863694
> write(3, "20030917-22:41:34 Info: sendMes"..., 54) = 54
> select(5, [4], NULL, NULL, {5, 0}) = 1 (in [4], left {4, 850000})
> recv(4, "\vMSH", 4096, 0) = 4
> select(5, [4], NULL, NULL, {5, 0}) = 0 (Timeout)
> recv(4, 0x8067930, 4096, 0) = -1 EAGAIN (Resource
> temporarily unavailable)


This sounds like the packets are not being sent for whatever reason. I
would suggest running tcpdump at your filewall to be absolutely sure,
but I've never seen a Linux box (post 2.0 kernel) just drop data because
it felt like it. I also would imagine that the the Windows box isn't
just dropping data (if it's NT4.0+). My first suspect would be the
program sending the data.

This is TCP data right? Not UDP data that could have just been lost in
transit?

--
Mike Nugent
Programmer/Author/DBA/Admin
In search of employment, email for credentials
(E-Mail Removed)

"Chris B." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> I'm running redhat 9.0 and windows 2000 professional. From my linux
> box I have a client that sends and receives data via a socket to a
> windows server application. The server writes many small packets (~30
> packets, 1-10 bytes) back to the client as an ack. The server
> application is not ours and we can't change it.
>
> In the linux client, I continue to call recv to pull the entire
> message off the socket. There are times when I don't receive all of
> the bytes that the server application says it sent. tcpdump on the
> linux box confirms that the data never arrives.
>
> We are not sure if one or more packets is being dumped via overflow on
> either the Windows box or the linux box. Attached is a part of the
> strace. Any ideas?
>
> Are there any windows or linux kernel level settings that may need to
> be modified?

In raw IP and UDP it's perfectly normal that some packets are lost. The
using application has to comply with the fact. TCP takes care of ensuring
that all bytes sent will arrive.

Do not think that a single TCP send will arrive in a single receive - TCP is
a byte stream which may be sent in pieces of whatever size the transport
protocol deems appropriate. There may be delays due to buffering inside the
transport.

The payload data must be structured so that it is possible to detect the
message boundaries from the contents of the data alone, e.g. byte counts at
start of records or flag bytes etc.

HTH

Tauno Voipio
tauno voipio @ iki fi