[zeromq-dev] QoS Features?

Peter Witkowski pwitkowski at gmail.com
Mon Oct 6 22:16:34 CEST 2014


Hello,

Forgive my ignorance, but I am looking at using 0MQ and moving away from
using the Linux socket APIs that I'm used to.  I have gone through a good
amount of documentation, and haven't found a direct answer to my question.

I have a system that is the classic request-response architecture in
unicast.  In my case, the request is actually a device command and the
response is an acknowledgement to that command.  In my application, I
handle retransmission of commands if necessary.  There are a few cases
where I do not want to retransmit the command, however (e.g., by the time I
catch a timeout, too much time has passed).  The system runs on very spotty
wireless links and I cannot guarantee a solid connection (packet loss of
greater than 50% is not uncommon).

I noticed that TCP is used as the underlying transport for 0MQ.  I also saw
a lot of discussion (on this mailing list) about people asking for UDP and
haven't seen a good amount of traction gained from these discussions.

I think what I'm looking for (and I'm wondering if there's something
similar in 0MQ somewhere) is a configurable Quality of Service (or just UDP
transport).  I understand that there are some packets/schemes where I want
guaranteed arrival, but for my application "best effort" is what I want.
Also, I want to have the ability to handle not receiving an ACK on my own
terms, instead of relying on TCP to retransmit at whatever rate it desires.

Are there (or are there planes for) such features in 0MQ?  Have others
implemented similar designs in 0MQ (where I have a predefined, legacy
command-ACK architecture)?  I already have a set, defined packet that I
have to send and an ACK that I have to look for afterwards.  TCP in my case
would be very redundant, since my specification calls for ACKs to be
handled at the application level.

Thank you in advance for your help.
-- 
Peter Witkowski
pwitkowski at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141006/32fc04ad/attachment.htm>


More information about the zeromq-dev mailing list