[zeromq-dev] Adapting Ch7:fileio3 example to support "uploads"

[Adam Zegelin]

Hello,

I'm attempting to adapt the fileio3 example from the ZeroMQ Guide (chapter
7) so that it performs uploads rather than downloads in the same manner
where the receiver gives the sender "credits".

I have a few goals:

   - The receiver is on a known address, hence it bind()'s its socket
   making it the "server".
   - The sender is on an unknown address and could be behind NAT, hence hit
   has to connect() to the receiver making it the "client".
   - Uploads are only one part of the communications between the sender &
   receiver, hence I'd like the sender to have the ability to switch the
   receiver into "receiving mode".
   - Uploads are just a data stream, hence credits only permit more data to
   be sent rather than specifying chunk number/offset in some "file".


I started to play around with pyZMQ to get a feel for how this could work.

My sender connects a DEALER to the well known address.
At that well known address the receiver binds() a ROUTER.

The sender sends "start" to the receiver to initiate a file transfer.
The receiver then sends an initial bunch of credits x "credit" messages.
The sender, on receipt of a "credit" message, sends a "chunk" message
containing a chunk of data.
The receiver, on receipt of a "chunk" message, sends another "credit"
message (assuming credits remain)
When the stream of data is consumed, the sender sends "bye" and then
disconnects.


While this appears to work, I did encounter some problems:

If the sender is started before the receiver, things break.
The sender, which creates a DELAER socket and connects() it to the
receivers ROUTER, doesn't appear to block on send().
I find this odd, since the zmq_socket(3) man page states:

When a ZMQ_DEALER socket enters an exceptional state due to having reached
> the high water mark for all peers, or if there are no peers at all, then
> any zmq_send(3) operations on the socket shall block until the exceptional
> state ends or at least one peer becomes available for sending; messages are
> not discarded.


I'm also unsure how to handle multiple senders connected to the one
receiver. I'm assuming I need to somehow store a state-machine state +
number of credits per socket identity.

Does anyone have some advice on how to best achieve my goals or have
example of a similar implementation that I can refer too?

Regards,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170306/9efc1022/attachment.htm>