[email protected] said: > 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.
Correct, this is what I meant by simple applications using recv() and more sophisticated ones using recvmsg(), the exact semantics of which wrt 0MQ we still need to define... > 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, is there some reason why the semantic of recv() only succeeding if enough buffer space is given to read an entire message part, and otherwise returning EMSGSIZE is no good? I.e. explicitly disallowing partial reads? It protects nicely against accidental buffer overflows. -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
