Maximum limit on size of data in IPC using sockets in unix

Question

I am using AF_UNIX,SOCK_STREAM socket for IPC between 2 different processes. The client is sending data over the socket which the server picks up and processes. The size of each block of data that the client writes to the socket is roughly 13 kilobytes using the following command:

Send Command in client : send(s, txPackDisp, sizeof(float)*PACKET_LENGTH, 0);

However, when I receive the data on the server using the following command :

Receive command in server : recv(s, bfoData, PACKET_LENGTH*sizeof(float),0);

the data received everytime is only partial of what I send (there are a lot of zeros in the end which should not be the case).

So my questions are :

1. Is there a limit on the maximum limit on the size of data that I can send over the AF_UNIX,SOCK_STREAM socket ( from what I have read , I dont think there is )

2. Does the socket break up the data into smaller blocks when transferring and if thats the case do I need to receive the smaller blocks individually or as single block like I am doing right now.

3. Will it be better to use AF_UNIX,SOCK_DGRAM socket here.

P.S : The source code for the main functions for the server and client can be seen in this question : IPC using Unix Domain Sockets

Answer 1

Q1) Is there a limit on the maximum limit on the size of data that I can send over the AF_UNIX,SOCK_STREAM socket ( from what I have read , I don't think there is )

You are correct. There is no real limit for SOCK_STREAM.

Q2 a) Does the socket break up the data into smaller blocks when transferring

You are correct. The stream is broken up into a manageable sized packets, negotiated by both the transmitter and the receiver.

Q2 b) and if thats the case do I need to receive the smaller blocks individually or as single block like I am doing right now.

You needn't do anything. The stream is reassembled on the other end, just as it was transmitted.

Q3) Will it be better to use AF_UNIX,SOCK_DGRAM socket here.

No. Unless you need to learn all about packet-size negotiation, checking for missing packets and having them resent, making sure that packets received out-of-order are managed properly, etc.

Answer 2

For SOCK_STREAM sockets, message boundaries are not preserved. The system can segment the message into multiple messages at the remote end.

SOCK_DGRAM sockets, on the other hand, always either send the whole message or none of it.

See: POSIX spec for socket:

SOCK_STREAM Provides sequenced, reliable, bidirectional, connection-mode byte streams, and may provide a transmission mechanism for out-of-band data. SOCK_DGRAM Provides datagrams, which are connectionless-mode, unreliable messages of fixed maximum length.

and send:

If the message is too long to pass through the underlying protocol, send() shall fail and no data shall be transmitted.

In the case of AF_UNIX the main determining factor which will decide whether a message can be sent is availability of contiguous buffers large enough to accomodate your data. Since you are sending 13KB this is not likely to be an issue either way.

If you stick with SOCK_STREAM, then your receiving code needs to be prepared for the fact that a single call to recv may not retrieve a whole message as sent by the sender. recv will return the number of bytes actually received, or -1 if there is an error. If the messages are fixed length then you can repeatedly call it until you have the whole message.

If you switch to using SOCK_DGRAM then you can be assured that the whole message will be sent in one hit, but there will be a limit to how big the messages you can send. 13KB should be fine though.

In general, SOCK_DGRAM is not guaranteed to be reliable or for the messages to be delivered in sequence. However in most unix implementations, AF_UNIX datagrams are reliable and will not be reordered (see: man unix. Check the man page for your flavour of 'nix to see if that applies).