[zeromq-dev] Usage of POLLOUT on stream sockets

[Nils Braun]

Dear Robert, all,

maybe I was not clear enough (although irrelevant for this question), 
but let me clarify: I have a full set of applications based on zmq 
(specifically the C++ bindings, which I really like) connecting around 
3200 processes which each other. The final application in the pipeline 
has to speak with a legacy application which I can not change (I can not 
just port it to zmq). In principle I could just use a standard tcp 
socket for this connection, but It would be so much nicer in my 
implementation if this is also a zmq socket...

I certainly do not want to "re-write zeromq"! :-)
The final application in the pipeline understands zmq on one side (with 
all its benefits) and (after some internal stuff) dumps data to the 
legacy application (without the benefits).

Anyways, my question was really more about the definition/meaning of 
POLLOUT for ZMQ_STREAM sockets.

Best,
Nils

On 10.07.19 19:31, Bob Eby wrote:
> Dear Nils,
>
>> I would like to connect my ZeroMQ application with a
>> non-zeromq one via a ZMQ_STREAM socket type.
> I think, in my way of looking at it, that you wouldn't be connecting
> to a non-zeromq application.  Instead, you'd be writing your own
> implementation of the zeromq protocol in order to communicate with the
> zeromq library over (part of) the zeromq protocol.
>
> Why would you need to re-write zeromq?  Certainly, it will be
> educational...  But I'm not sure I could recommend this scenario in
> any conceivable production setting.
>
>> Is it possible to test if the socket is writable and a send
>> would not block via the usage of poll (with POLLOUT)?
> I've really only used REQ / REP with DEALER / BROKER myself.  I can
> say that in my configuration ZeroMQ will definitely block on certain
> calls.  Most notably, all data must be completely sent before the
> remote side will begin reading any result.  I think this is partly
> fundamental to how "queuing" works in ZeroMQ.  Some level of data
> chunk will always be fully completed and secured (usually at message
> level) before the remote end can begin to dequeue that chunk.
>
> Someone please correct me if I'm wrong here.  I have not read the code!
>
> Good luck with your configuration,
> Robert E.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev