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
