Hi Pieter, Mato,
>> I trust you see why forcing a length-specified frame recv into an API
>> designed for streams is not the most brilliant idea.
Couple of points:
1. recv() is part of POSIX API, so "not having it" is not an option. The
closest behaviour you can get is recv() returning ENOTSUPP.
2. There's at least one use case for receiving into fixed buffer, namely
processing a feed of small messages, such as market data:
zmq::socket_t s (ctx, ZMQ_SUB);
s.setsockopt (ZMQ_MAXMSGSIZE, 200);
s.setsockopt (ZMQ_SUBSCRIBE, "");
char buff [200];
while (true) {
s.recv (buff, 200);
...
}
3. Large messages and/or messages with a size unknown in advance should
be better receiving using zero-copy:
zmq::message_t msg;
s.recvmsg (&msg);
and thus fall out of scope of simple recv() function.
4. However, accidental buffer overflows should be handled somehow. The
existing POSIX options I am aware of are either mimicking UDP or
mimicking SCTP. I would say the former is the best fit as the latter
(SCTP's partial delivery) is designed for receiving large messages,
which is already handled by recvmsg() in 0MQ.
Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
