[zeromq-dev] STREAM sockets merge two chunks of data on a single recv

[André Caron]

Stream sockets are basically glorified TCP sockets.  They don't have any
framing, which means that there is no way to guarantee the receiving peer
will receive the same number of chunks you send.  Some things that can
happen:
- peer receives chunks as sent (likely if chunks are small AND there is
enough time between sends);
- peer receives all data in fewer, but larger chunks;
- peer receives all data in more, but smaller chunks;
- peer receives part of one chunk before a disconnection.

In order to make sure the peer is atomically delivered each chunk you send,
you need framing support in the protocol.

André

On Tue, Mar 3, 2015 at 4:09 PM, Amr Ali <amr.ali.cc at gmail.com> wrote:

> While testing an API implementation where I use 0MQ STREAM socket to
> send data to a server that uses vanilla TCP socket to receive the data I
> noticed something peculiar that failed my tests.
>
> In my tests I use a 0MQ STREAM socket to mock the service's server TCP
> socket.
>
> So my API function does multiple consecutive `send()`s (exactly 3), and
> in my unit test function I do 4 `recv()`s (the first is to get the
> client identity). The 3rd `recv()` returns the data both the 2nd and 3rd
> `send()` sent, and the 4th `recv()` times out.
>
> API sends:
>
> [First Message]
> +++ some code +++
> [Second Message]
> +++ some code +++
> [Third Message]
>
> Test Receives:
>
> [Client Identity -- no data]
> +++ some asserts +++
> [First Message]
> +++ some asserts +++
> [Second Message + Third Message]
> +++ some asserts +++
> [This recv raises EAGAIN]
>
> Does libzmq internally make sure to flush data on a STREAM socket before
> other `send()` calls?
> --
> Amr
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150303/9585e1db/attachment.htm>