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

This is a discussion on Is it portable, the unix domain socket one-to-one correspondence - Linux ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

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

  1. 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


  2. Re: Is it portable, the unix domain socket one-to-one correspondence

    "Bin Chen" writes:

    > 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.


    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}

  3. Re: Is it portable, the unix domain socket one-to-one correspondence


    Bin Chen wrote:

    > 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.


    > 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.


    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


  4. Re: Is it portable, the unix domain socket one-to-one correspondence



    On Dec 30, 6:40 am, "David Schwartz" wrote:
    > Bin Chen wrote:
    > > 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.
    > > 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.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.


    Thank you very much!
    >
    > DS



+ Reply to Thread