STREAM is meant for interoperability with existing TCP services. It makes no sense to use this for your own new protocols. This is the basic thing ZeroMQ always did: copy a stream into frames.
On Wed, Mar 4, 2015 at 6:36 AM, Amr Ali <[email protected]> wrote: > When you say "chunks", do you mean parts of a multi-part message being > sent using send_multipart with the MORE flag set? > > On 03/04/2015 12:12 AM, André Caron wrote: >> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > -- > Amr > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
