(Originally posted to comp.os.linux.development)
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
Any help would be appreciated.