Hi Toon, You may also read RFC 23 since that covers the current version of ZMTP and may be more helpful.
-Pieter On Wed, Jan 15, 2014 at 12:24 PM, Toon Peters <[email protected]> wrote: > Hey guys, > > Thanks for your replies! I've managed to get it working now. > Pieter was right, all the documentation is on the :15 rfc page, but without > an initial overview it's quite hard to wrap your mind around everything. > > PUB-SUB will soon be available in our repo. > > With kind regards > > Toon Peters > Embedded Software Engineer > > E [email protected] | W www.tass.be > > Disclaimer | The information transmitted is intended only for use by the > addressee and may contain confidential and/or privileged material. Any > review, retransmission, dissemination or other use of it, or the taking of > any action in reliance upon this information by persons and/or entities > other than the intended recipient is prohibited. If you received this in > error, please inform the sender and/or addressee immediately and delete the > material. Thank you. > Please consider the environment before printing this email > > > On 14 January 2014 12:33, Bruno D. Rodrigues <[email protected]> > wrote: >> >> Inline >> >> On Jan 14, 2014, at 11:19, Toon Peters <[email protected]> wrote: >> >> Dear All, >> >> I'm currently trying to improve our ZeroMQ implementation on our TCP/IP >> stack called PicoTCP (All the source files can be found at >> http://github.com/tass-belgium/picotcp/) >> >> I'm currently trying to figure out all of the ZMTP 2.0 fields in the >> protocol, but I have noticed that some implementations don't really seem to >> adhere to the protocol. >> >> example: I'm using the pyzmq library and have one publisher and one >> subscriber. Here's what's happening on byte level: >> >> Sub -> Pub >> Signature: FF 00 00 00 00 00 00 00 01 7F ( the signature mentions 8 times >> 0x00, while the documentation below mentions 8 octets + 1. Could you provide >> any clarification here? >> Revision: 01 (= V2.0) >> Socket type: 02 >> >> >> FF + 8 bytes (ignore them?) + 7F >> >> Further bytes: >> 0x00 0x00 (=final short? what does the second byte stand for? length of >> body?) >> 0x00 0x01 0x01 (= body? What's the function of the body?) >> >> >> greeting = signature revision socket-type identity >> >> 0x00 0x00 = final short value 0 = no identity >> >> >> connection = greeting *message >> >> 0x00 0x01 0x01 = message final (no more) with short len = 1 and value = 1 >> means SUBSCRIBE (value 0 means UNSUBSCRIBE) >> >> I guess if nothing follows, it’s the case of subscribe all (0 bytes) >> >> >> Pub -> Sub >> signature: FF 00 00 00 00 00 00 00 01 7F >> Revision: 01 >> Socket type: 01 >> >> Further bytes: >> 0x00 0x00 (=final short? nothing in the body?) >> >> >> same identity situation >> >> 0x00 0x0C [Data] (shouldn't the first byte be 0x01 (more short)) >> >> >> message final without more, with 12 bytes following? >> >> >> When sending larger chunks of data (> 255 bytes), the data part changed >> into >> 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0xAB 0xCD (= more-long ? But the start >> byte is not 0x03) >> >> >> 0x02 = message final without more, with 8 bytes len (43981 bytes?) >> >> >> http://rfc.zeromq.org/spec:15 >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
