[zeromq-dev] Multicast messages corrupted

[Alexander Zhitlenok]

This is what we really have. In that part of our app, we have multiple clients send short messages to one subscriber. As soon as message receives we do nothing but print (in log) number of frames and the first integer from the frame, which is our message ID. (After that we put the message in a queue and process it in another thread). Since our messages are short, all the messages are single-frame ones. However at some moment subscriber receives 3-4-frames message with garbage ID (first int). We see, these unexpected messages come "in pack", 3-5 at the same time. After getting these 3-5 unexpected messages (actually, processing is just catching an exception and doing some logging) no more messages come.
When I say "we receive message", I mean we do nothing but call ReceiveFrame for ZmqSocket object (clrzmq.dll)

I can easily admit that we are doing something wrong, but we do not do anything at the stage of messages initial receiving.

Thank you,
Alex
(we use win7\epgm\clrzmq)


From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Steven McCoy
Sent: Tuesday, July 23, 2013 8:19 AM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] Multicast messages corrupted

On 22 July 2013 15:06, Alexander Zhitlenok <AZhitlenok at geneva-trading.com<mailto:AZhitlenok at geneva-trading.com>> wrote:
All works fine, sometimes for hours, however at some unpredictable moment we start receiving corrupted messages. After 4-5 corrupted messages, our custom C# layer stops receiving messages. I'm not sure yet (still testing) does Zmq Cpp-layer still receive messages or not?


Ideally it should not be corrupted messages from the wire as each packet is checksum verified.

This leaves corruption in software and hardware.  You really need to capture in parallel with other clients to narrow down the scope of corruption.  The implication in your message is that multiple Windows machines are receiving and thus it is likely to be somewhere in the software stack.

Preferably a capture of the wire traffic would be recommended to try replaying.

--
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130723/df200fef/attachment.htm>