[zeromq-dev] ZMQ_STREAM with inproc ?

Laurent Alebarde l.alebarde at free.fr
Wed Feb 12 09:25:50 CET 2014

Le 11/02/2014 10:18, Goswin von Brederlow a écrit :
> 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()));
>    exit(1);
> }
> 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.
That's a killing argument.
>>>> 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.
I agree. I have already spent far to much time inside libzmq.
> MfG
> 	Goswin
> _______________________________________________
> 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/20140212/65dc4a10/attachment.htm>

More information about the zeromq-dev mailing list