Hi Robert, This seems to be a bug in 2.1. It doesn't happen with 3.0 & 3.1. Feel free to fill in an issue in the bug tracker.
A comment on wireshark dissector (I've written the AMQP dissector so I have some minimal experience in the area): IIRC wireshark starts dissecting every packet from the beginning. This assumes that the application protocol elements are aligned with TCP packets. This works OK in most cases as the applications tend to write protocol elements to the socket using separate send() invocations. That in turn in most cases results in protocol elements being aligned with TCP packets. However, given that 0MQ does aggressive message batching protocol elements are often not aligned with TCP packets :( This effect should be visible when sending a lot of messages at the same time. You can use throughput test in the perf ubdirectory to emulate it. When sending messages sporadically, the dissector should work OK though. Martin On 7/12/2011, "Robert G. Jakabosky" <[email protected]> wrote: >When sending messages with zmq 2.1.10 some of the reserved bits (1-6) are set >to one instead of zero like the ZMTP/1.0 specs [1] says. The spec says that >they MUST be zero. Having the reserved bits set to one will cause >compatibility problems when later versions want to set those bits for new >features, so I think this is a bug in the zmq library code. > >I found this out when working on a zmq protocol dissector [2] for Wireshark. > >1. http://rfc.zeromq.org/spec:13 >2. https://github.com/Neopallium/lua-zmq/tree/master/ws > >-- >Robert G. Jakabosky >_______________________________________________ >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
