On Tuesday 06, Martin Sustrik wrote: > 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.
https://zeromq.jira.com/browse/LIBZMQ-293 > 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 :( Yup, already have support for TCP reassembly to deal with the frames that don't align with the TCP segments. The only issue right now is if someone starts capturing packets in the middle of a TCP session and the first packet captured start with a partial zmq frame, then it will be out-of-sync for all frames after that. > 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. That is what I used for testing the dissector. I have also tested multi-part messages. One thing I might add later is the grouping of frames into messages, right now it just shows all the frames in one list grouped by the packet/tcp segment (reassembled frames end up in there own "packet" group). > 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 -- Robert G. Jakabosky _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
