This approach might allow seamless integration of forward error correction libraries as well.
> On Feb 1, 2014, at 7:42 AM, Goswin von Brederlow <[email protected]> wrote: > > Hi, > > zmq is a message based protocol and application always recieve > messages as a whole. > > Not so with ZMQ_STREAM sockets. There the application gets the data in > whatever chunks it happens to arrive. Sometimes even a byte at a time > if that is how it comes in. > > Now often the data transmitted on a ZMQ_STREAM socket has some > structure. For example HTTP traffic is made up of lines terminated by > \r\n and those lines make up requests also terminates by \r\n (so you > get \r\n\r\n at the end of a request). And replies have a header (same > \r\n encoding) and content. > > So wouldn't it be neat if zmq_msg_recv() could block until a full HTTP > request was recieved and deliver that as either a single message frame > or already split by lines into key:value pairs? Similar for the reply, > it could be 2 frames: One for the header and one for the content. > > > Now I'm not suggesting to add a HTTP protocol parser to zmq. That is > not its job. But zmq internally already has some meachnism that covers > a range of different zmq protocol versions using different encoders > and decoders. Why not allow the user to specify encoder and decoder > callbacks for ZMQ_STREAM sockets? Then other protocols like HTTP could > be implemented as custom encoder/decoder and passed to zmq for use. > > Thoughts? > > 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
