By any chance, aren't you deallocating the memory passed to ZMQ send
function right after the send call? The sending is not "done" during the
send call, so unless you copied the memory to the message buffer, you must
preserve the memory. You can specify your own deallocate function, which
will be called by ZMQ internals when sending is done.
Best regards
Radek Svoboda
On Fri, Jul 21, 2017 at 5:44 PM, <david.my...@avalesta.com> wrote:
> Hello,
>
> I have a windows 64-bit project where two processes (windows exes) connect
> via ZeroMQ.
>
> Process 1, the plugin process, collects video frames and decodes them.
> This process sends the decoded frames to process 2, the GUI, for display.
>
> I originally used REQ REP sockets, with the plugin as the REQ sending to
> the GUI, the REP, which then sent an Acknowledge back after each data
> frame. However, this model meant that the sending (plugin) process was
> waiting up to 20ms for an Ack from the GUI before it could send the next
> frame and so, because the data only went one way, we changed the model to
> PUSH PULL. This is when our troubles began.
>
> After sending a random number of frames, the sending process (the PUSH
> socket) is crashing in tcp.cpp, here:-
>
> int zmq::tcp_write (fd_t s_, const void *data_, size_t size_)
> {
> #ifdef ZMQ_HAVE_WINDOWS
>
> int nbytes = send (s_, (char*) data_, (int) size_, 0);
> .
> .
> }
>
> nbytes is returning -1 and the error code is 10014 WSAEFAULT bad address.
> I seem to be overflowing the Send data buffers or perhaps sending too fast
> for the receiver process to receive the data on the PULL socket.
>
> The only way I can seem to avoid this error is put a Sleep(20) ie sleep
> for 20ms, after each send. With this sleep I'm back where I started with a
> 20ms delay between image frame sends.
>
> Is this really how PUSH PULL sockets work?
>
> How can I send data as fast as possible? If I have to skip frames at the
> receive end, I don't really care too much, but I need a robust mechanism
> and I thought ZMQ was made for this type of data transfer.
>
> Many thanks for any help or ideas.
> David
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
