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://127.0.0.1:5556" 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
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
