CODEWITHSUNDEEP
c++network-programmingzeromq
user2290362
user2290362

Reputation: 717

ZMQ PUSH PULL half of each message sent

I'm trying to send a stream of images, each one about 3.5Mb. To send, I'm using code of the format:

zmq::socket_t sender (*context, ZMQ_PUSH);
sender.connect("tcp://....:5556");
while(...){
    zmq::message_t msg (data, (size_t)camHeight*camWidth, NULL,NULL);
    sender.send(msg, ZMQ_NOBLOCK);
}

And to receive:

zmq::socket_t socket(zmqContext, ZMQ_PULL);
socket.bind("tcp://*:5556");
zmq::message_t msg;

while(..){
    socket.recv(&msg);
    unsigned char* data = (unsigned char*) msg.data();
    ...
    outFile.write ((char*) data, msg.size());
}

All of the images I'm expecting to come through do come through and the size of msg is as expected, however, the image is "clipped" - up to a horizontal line on the image (the same line in every image), the image is correct, and after that it is totally black. Occasionally in the black section, there is some noise.

Does anyone have an idea of what might cause this?

Upvotes: 1

Views: 543

Answers (1)

user3666197
user3666197

Reputation: 1

What might cause this? Wrong data manipulation, not ZeroMQ

ZeroMQ sending functions ( in both of it's flavours, be it self-counting the data.sizeOf() or not ) move transparently & literally whatever you pass it to send.

As much bytes ( or as few bytes ) as it is instructed to send it does send.

No exceptions, no excuse.

So if you instruct ZeroMQ to send only a fraction of the original, there you go. You get just that fraction, that you have indicated ( be it intentionally or in error ).

How to prove that?

Repair your data-"framing" ( in this case data-"cut-off" ) or use a safer-mode, self-wrapping container to deliver your content independently of it's variable sizing.

If in doubts, just try to put your image-data into a JSON or even more human-readable case, store it inside a ZIP-file for such a test.

Then, move it accross the ZeroMQ messaging-layer and try to reconstruct the data from inside the JSON/ZIP-file.

There you will notice the source of the cut-off failure -- the wrong calculus of the data-size.

Upvotes: 1

Related Questions