[zeromq-dev] PicoTCP ZeroMQ implementation

[Toon Peters]

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 <toon.peters at tass.be> | W www.tass.be
<http://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140115/266eab33/attachment.htm>