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

[Daniel Krikun]

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().
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131228/23c73853/attachment.htm>