Very Computer

(Originally posted to comp.os.linux.development)

Hello All,

I have an application that reads and writes from TCP/IP sockets. I know that
according to the spec, TCP/IP sockets should be 100% guaranteed. That is, if
I write "hello world" to one side of the socket, I should be able to always
read "hello world" from the receiving side of the socket.

What we are seeing is that occasionally a read of the socket will return the
correct size of bytes (ie. 11 as in the "hello world" example), but the data
will be all hex 0's. We prefill the receiving data area with bogus
characters and immediately check it after the read and it will be all 0's so
we know the received data is 0's. Now it doesn't do this all the time, just
occasionally and usually only when we are doing a lot of writes on the
socket with no time delays between the writes.

If we insert a delay of some time, either a sleep() or usleep(), etc., then
the 0's go away. It is almost as if we are overrunning the buffer for the
socket. I just thought with TCP/IP that this was impossible.  The
application receives messages from client programs and is relaying them
using TCP/IP sockets to another program. It is trying to relay them as fast
as possible, ie. write them out one after the other on the socket.

As the subject indicates, this is on Redhat 7.2 using the glibc libraries
and gcc as the compiler. The computers using the sockets are on the same
network hub.  If it is a buffer problem, shouldn't the write() return an
error indicating to us that we are overflowing the network buffer? We tried
doing read() and recv() on the receiving end and the problem appeared with
both functions.

Any help would be appreciated.

Jim

I doubt this is a bug in the TCP implementation. Most likely it is a
bug in your program. Are you sure you always call read and write with
a correct pointer for the buffer? Are you sure you always call with
the correct size? And are you sure you check the return code from the
read and write calls. They might read or write less bytes than
requested.

And btw. I never use send or recv on TCP sockets. I don't see much
reason for that, just stick with the simpler read and write functions
which work just fine on TCP sockets.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);