[zeromq-dev] PicoTCP ZeroMQ implementation

[Pieter Hintjens]

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 <toon.peters at tass.be> 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 toon.peters at tass.be | 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 <bruno.rodrigues at litux.org>
> wrote:
>>
>> Inline
>>
>> On Jan 14, 2014, at 11:19, Toon Peters <toon.peters at tass.be> 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
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>