[zeromq-dev] ZMQ_STREAM with inproc ?

Goswin von Brederlow goswin-v-b at web.de
Tue Feb 11 10:18:39 CET 2014

On Mon, Feb 10, 2014 at 05:38:44PM +0100, Laurent Alebarde wrote:
> Le 10/02/2014 11:12, Goswin von Brederlow a écrit :
> >On Sun, Feb 09, 2014 at 12:16:48AM +0100, Laurent Alebarde wrote:
> >>When I replace the tcp address "tcp://" with an
> >>*inproc* one, say "inproc://testStream", in /tests/test_stream.cpp/,
> >>the test fails. It asserts on
> >>
> >>rc = zmq_recv (stream, buffer, 255, 0);
> >>     assert (rc == 0);
> >>
> >>The documentation for sockets says: "/A socket of type 'ZMQ_STREAM'
> >>is used to send and receive TCP data from a //
> >>//non-0MQ peer, when using the tcp:// transport/.", so, possibly the
> >>cases other than tcp are not valid ?
> >>
> >>If the answer is positive, I think it should assert as soon as the
> >>socket  binds or connects to a none tcp address.
> >Please don't assert. return an error. An application can never handle
> >an assert and give a good error, like e.g "Wrong transport type
> >specified in conffile".
> If ZMQ_STREAM can work only with the tcp transport, I don't see what
> kind of handling the application could do when a ZMQ_STREAM socket
> is connected or binded to an illegal transport ?

Simplest case:

If (zmq_connect(address) == 1) {
  fprintf(stderr, "Failed to connect: %s\n", zmq_strerror(zmq_errno()));

Saying why it fails is far better than getting an "assertion failure".
Also the program doesn't have to exit(1). Think of an interactive
application where the user enters the address to connect to.

> >>As ZMQ_STREAM has a raw behaviour, it is interesting for many
> >>things. It would be nice to be able to use the other transports with
> >>it.
> >It might be nice to use udp or multicast. Does that work? Maybe even
> >ipc.
> >
> >But I fail to see the use case for inproc. For other transport types
> >there is a boxing of messages for the on-wire protocol. But inproc has
> >no on-wire. It directly puts the send message into the recievers pipe.
> >So saying you don't want any boxing of the data makes no sense to me.
> What lacks for me is a real raw socket type working on any transport.
> >
> >MfG
> >	Goswin

Inproc skips the transport layer. That makes it extremly fast but
makes it incompatible with STREAM sockets or CURVE.

For the STREAM + inproc case you would want a new socket class that
goes through all the encoding/decoding and encryption layers and at
the end, where data usualy is written to a file descriptor, you want
to dump the data back into a pipe. Sounds horrible to implement from
the code flow I've seen so far.


More information about the zeromq-dev mailing list