socket buffer problem!?!

socket buffer problem!?!

Post by Adnan Klancev » Sat, 26 Jul 1997 04:00:00



Hello there

I've just started a small sockets program.  Basically, the client sends a string to the server.  Upon receiving this string, the server sends another string to the client....  

SERVER:
read(msgsd, buf, sizeof(buf) );
puts(buf);
write(msgsd, "Hello from server", sizeof(buf));

CLIENT:
write(sockfd, "Hello from client", sizeof(buf));
read(sockfd, buf, sizeof(buf));
puts(buf);

When 'buf' is 100 bytes long, the messages get through without a problem.  However, when I increase the size of 'buf' to 500 bytes, the client blocks on the read().  The situation used to be worse, I couldn't send messages larger than 50 bytes but after enabling the TCP_NODELAY option the situation has improved to where it is now.  Could someone explain the logic behind this behaviour?  I suspect that it might have something to do with the size of the I/O buffers for the socket but I'm not sure.  Any feedb

ack would be much appreciated.  Thanks in advance.

regards,

Adnan Klancevic

 
 
 

socket buffer problem!?!

Post by Andrew Giert » Sat, 26 Jul 1997 04:00:00


[reformatted with extreme prejudice to remove 510-column lines]

 Adnan> Hello there

 Adnan> I've just started a small sockets program.  Basically, the
 Adnan> client sends a string to the server.  Upon receiving this
 Adnan> string, the server sends another string to the client....

 Adnan> SERVER:
 Adnan> read(msgsd, buf, sizeof(buf) );

Bang.

You *MUST* look at the return value of *EVERY SINGLE* read() call on
a socket. read() *will* read less data than you asked it to.

 Adnan> When 'buf' is 100 bytes long, the messages get through without
 Adnan> a problem.  However, when I increase the size of 'buf' to 500
 Adnan> bytes, the client blocks on the read().  The situation used to
 Adnan> be worse, I couldn't send messages larger than 50 bytes but
 Adnan> after enabling the TCP_NODELAY option the situation has
 Adnan> improved to where it is now.  Could someone explain the logic
 Adnan> behind this behaviour?  I suspect that it might have something
 Adnan> to do with the size of the I/O buffers for the socket but I'm
 Adnan> not sure.  Any feedback would be much appreciated.

Get rid of TCP_NODELAY.

Socket FAQ is at http://kipper.york.ac.uk/~vic/sock-faq/

Your problem is assuming that read(sock,buf,len) will read len bytes
of data from the socket. It won't. It'll read as much data as is
immediately available, but no more than len bytes.

Also, remember that the boundaries of the write() calls are *not*
preserved.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

 
 
 

socket buffer problem!?!

Post by Bjorn Ree » Sat, 26 Jul 1997 04:00:00



> SERVER:
> read(msgsd, buf, sizeof(buf) );
> puts(buf);
> write(msgsd, "Hello from server", sizeof(buf));

The last argument must be the lengh of the "Hello from server"
string, not the size of the buffer.

  sprintf(buf, "Hello from server");
  write(msgsd, buf, strlen(buf));

 
 
 

socket buffer problem!?!

Post by Andrew Giert » Sat, 26 Jul 1997 04:00:00



 >> SERVER:
 >> read(msgsd, buf, sizeof(buf) );
 >> puts(buf);
 >> write(msgsd, "Hello from server", sizeof(buf));

 Bjorn> The last argument must be the lengh of the "Hello from server"
 Bjorn> string, not the size of the buffer.

No, the last argument should be the number of bytes to send. The
interpretation of those bytes is the responsibility of the application
:-)

Using write(sock,buf,strlen(buf)) is actually wrong unless the string
is self-delimiting, or the length has been previously sent, since
write boundaries are not preserved across a socket.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

 
 
 

1. Socket buffer problem?

I am working on comparing the performance of two different socket
protocols under Sun OS.  These are the Unix Datagram Protocol and the
streams protocol.  I'm trying to determine things such as maximum
packet size on UDP (I think it's ~8K), and ave. times for the
transmission of relatively large chunks of data.  The strange thing
is that when I send 2k data chunks with no delay, the receiver
gets weird stuff.

I'm sending 2k of data, followed by 10 bytes of debug stuff, 2k of data ...

What happens is that the 10 bytes of debug data never get received
if my receiving process does two quick reads.  However, if I put a
delay between the reads, everything works.  Essentially, I must be
overrunning some sort of receive buffer, but I get no error messages back.

Any ideas?

David Croley

2. Adaptec2940-Maxtor LXT535SY problem

3. Socket Buffer Size Problem

4. RH 6.1 dhclient error alias eth0 off?

5. Linux Sockets, SendQ buffer problem!

6. Linux Certification options?

7. socket buffer size problem

8. Creating and script file

9. Socket buffer overflow problem with UDP multicasting.

10. buffer layer error at fs/buffer.c:127; problems with via686a sensor

11. Setting the buffer for a Socket.

12. memory used for socket buffers

13. Sockets, Stdio and Buffering