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" <[email protected]> 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 <[email protected]> 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" <[email protected]> wrote: > >> > >> On Sat, Dec 28, 2013 at 11:15 AM, Daniel Krikun <[email protected]> > >> 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 > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
