Problem with sockets--atomic read.
Posted on 1997-11-17
I'm having a problem performing a read() call and retrieving all of the data.
I'm using IRIX 5.3 on an SGI Indy. Here is the situation:
I have a socket opened for TCP/IP communication. My client
process performs a writev() call. The writev() is passed an
iovec with 2 buffers in it. The total size of the two
buffers is less than PIPE_BUF (aka: PIPE_MAX). The writev()
call returns to me with a positive value which is equal to
the number of bytes I expect to write. I believe PIPE_BUF
is 10240 bytes, and my writev() call is writing 3875 bytes
(well below PIPE_BUF). My server process then performs a
select() call to check for data on the socket and follows
that with a read(). The select() call is only checking for
data on a single socket and is used so that I can timeout
the recv() without using signals. Anyway, the select()
detects the data on the socket and then I perform a recv().
However, I am only able to read about 1500 bytes of the
message. If I place a sleep(1) call just prior to the
recv() I get the whole message (3875 bytes). This would
leave me to believe that recv() is returning prior to all
the data arriving on the socket. I would think that an
atomic write on a TCP/IP socket would gurantee that the
message is received atomically as well, but this does not
seem to be the case. I am wondering if there is some limit
imposed on TCP/IP sockets that is less than PIPE_BUF than I
should be using or do I just need to put that recv() call in
a loop with an accumulator and just keep trying to read
until all the data arrives?
Barry M. Caceres