[zeromq-dev] Is UDP transport needed in ZeroMQ?

[Michael Powell]

On Sat, Dec 28, 2013 at 11:05 AM, Daniel Krikun <dkrikun0 at gmail.com> wrote:
> What I wanted to say is that while patterns do simplify development, they
> have there peculiarities, in the example above, i'm doing non-blocking
> receive with REQ/REP which looks benign, but in fact it isn't because if the
> message is not obtained, i cannot send().

I don't know your code, but it sounds like a bug worst case, possibly
a feature request best case. You would likely need to report it,
probably clarify what you mean by "if the 'message' is not obtained",
what it is you mean by "I cannot send".

Plain-jane sockets, TCP or UDP, in and of themselves, are pretty
simple. Even if you factor in non-blocking, which most folks require.
Sounds like a bug in the logic governing their usage: i.e. the REQ/REP
pattern.

> On Dec 28, 2013 5:01 PM, "Michael Powell" <mwpowellhtx at gmail.com> wrote:
>>
>> Sockets development is not for the faint of heart, as you already know.
>>
>> On Sat, Dec 28, 2013 at 8:24 AM, Daniel Krikun <dkrikun0 at gmail.com> wrote:
>> > That's pretty good explanation!
>> > Few points though:
>> > - both plain tcp and udp are free
>>
>> True. Been there, done that. I've rolled my own C++ reader/writer,
>> client/server classes before. It's not rocket science, but you do need
>> to be aware of the issues.
>>
>> > - both plain tcp and udp are available for any language (here they
>> > certainly
>> > win)
>>
>> True.
>>
>> > - background io is great, however it is not straightforward to
>> > understand
>> > why then there is ZMQ_NOBLOCK option in send method
>> > - patterns are great too, especially for tcp, but they too can be hard
>> > to
>> > understand for newcomers, for example, it is a common problem that when
>> > using REQ/REP an application crashes due to uncaught exception, because
>> > somebody called recv() with ZMQ_NOBLOCK and the message has not been
>> > actually received.
>>
>> This is true for any asynchronous operation. When recv() (or read)
>> returns, you have to check the error code(s). If exceptions are
>> involved, use try/catch. This goes without saying.
>>
>> > Also, I have found it is hard to explain the difference
>> > between bind() vs connect() and patterns.
>>
>> This does not make any sense. Bind and Connect serve two different
>> purposes. You generally bind to an endpoint, usually address(es) plus
>> port(s), for both TCP and UDP. You Connect for TCP since it is
>> connection-oriented.
>>
>> You and/or your team should be using your critical thinking skills. If
>> you are in an I/O paradigm, this shouldn't be hard to grasp.
>>
>> > I'm not saying the patterns suck, they surely do not, personally I think
>> > they are very helpful, but they are not perfect.
>>
>> Again, nonsensical, IMO. If you're at a low-level I/O, you are dealing
>> with socket, bind, connect, etc. Goes with the territory in my
>> experience.
>>
>> > Maybe plain udp can be
>> > easier to grasp.
>>
>> The response here, as with most I/O like this, is: it depends. Is
>> connection-oriented, "reliable" your objective? Use TCP. Is
>> connectionless/messaging, "less reliable" (i.e. depending if/when your
>> clients are listening) your objective? Use UDP.
>>
>> Have done both in my C++ classes. Extending that into a pub/sub and/or
>> event-driven models worked real well.
>>
>> > On Dec 28, 2013 1:50 PM, "Pieter Hintjens" <ph at imatix.com> wrote:
>> >>
>> >> On Sat, Dec 28, 2013 at 11:15 AM, Daniel Krikun <dkrikun0 at gmail.com>
>> >> wrote:
>> >>
>> >> > The question is, what is the value of using zmq with udp transport
>> >> > over
>> >> > plain udp?
>> >>
>> >> http://zeromq.org/topics:omq-is-just-sockets
>> >>
>> >> -Pieter
>> >> _______________________________________________
>> >> zeromq-dev mailing list
>> >> zeromq-dev at lists.zeromq.org
>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>