Is it portable, the unix domain socket one-to-one correspondence

Hi,

I just did a experiment to check the UNIX domain socket's behavior,
there is a client and server, client send the data to server, and
server receives. Actually, I want to know if I write separate multi
messages to the server's socket, will it be packaged to one big message
if the server are not quick enough to read each individual message.

This experiment is simple, just start the server and let it to sleep
for 10 secs and in the mean time the client send multi message using
multi lines of write().

I expect the kernel will re-package all the received small messages to
a big one, but unfortunately, the kernel doesn't do that. It still need
multi read in server side to read all the pending messages. That is,
one write in client, there must be on read in server.

Is it portable, I want to know can I rely on this? Is it POSIX
compliant? If each message can be assured by kernel to be not
concatenated to others, the message length can vary, and easy for the
IPC protocol design.

Thanks a lot.
ABAI

"Bin Chen" <binary.chen@gmail.com> writes:
[color=blue]
> Hi,
>
> I just did a experiment to check the UNIX domain socket's behavior,
> there is a client and server, client send the data to server, and
> server receives. Actually, I want to know if I write separate multi
> messages to the server's socket, will it be packaged to one big message
> if the server are not quick enough to read each individual message.
>
> This experiment is simple, just start the server and let it to sleep
> for 10 secs and in the mean time the client send multi message using
> multi lines of write().
>
> I expect the kernel will re-package all the received small messages to
> a big one, but unfortunately, the kernel doesn't do that. It still need
> multi read in server side to read all the pending messages. That is,
> one write in client, there must be on read in server.
>
> Is it portable, I want to know can I rely on this? Is it POSIX
> compliant? If each message can be assured by kernel to be not
> concatenated to others, the message length can vary, and easy for the
> IPC protocol design.[/color]

if you want messages, use "SOCK_DGRAM". "SOCK_STREAM" does not
garantee that will be received with the same packing it was sent.

--
Philippe Amarenco, aka Phix
epita 2007 - EpX - ex-{GISTR,ACU,LSE}

Bin Chen wrote:
[color=blue]
> I just did a experiment to check the UNIX domain socket's behavior,
> there is a client and server, client send the data to server, and
> server receives. Actually, I want to know if I write separate multi
> messages to the server's socket, will it be packaged to one big message
> if the server are not quick enough to read each individual message.[/color]
[color=blue]
> Is it portable, I want to know can I rely on this? Is it POSIX
> compliant? If each message can be assured by kernel to be not
> concatenated to others, the message length can vary, and easy for the
> IPC protocol design.[/color]

You have two choices:

1) You can use UNIX domain stream sockets. These do not preserve
message boundaries but ensure reliable delivery.

2) You can use UNIX domain datagram sockets. These preserve message
boundaries but are only guaranteed reliable on some platforms.

Generally, the best solution when you need everything is to use UNIX
domain stream sockets and use some simple technique to specify the
message length. The following six techniques are commonly used:

1) If the message is text and never contains newlines, the message can
be delimited by a return/newline sequence.

2) If the message is text and contains multiple lines but never
contains an empty line, an empty line can be used to separate messages.

3) If the message is text and rarely contains empty lines, an empty
line can be used to separate messages and empty lines in a message can
be prefixed with a dot. If lines might start with a dot, you prefix
them with a dot as well. So ".foo" means "foo" and "..foo" means
".foo". "." means "end of message".

4) If the message is binary, you can include the message length before
each message. You can used a fixed number of bytes to encode the
message length in either a text or binary fashion.

5) If the message cannot contain a zero byte (if it's text), use a zero
byte to mark the end of a message. Use caution when processing such
messages in code because C uses a zero byte to mark the end of a
string.

6) If there is a character rarely used in the message, say 255, you can
change it into an escape character. The end of message can be marked by
a 255 followed by a 0. A 255 in the message can be encoded as two
255's. This leaves other escape sequences (like 255 1) for any purpose
you might come up with.

DS