On Sat, Dec 28, 2013 at 3:24 PM, Daniel Krikun <[email protected]> wrote:
> I'm not saying the patterns suck, they surely do not, personally I think > they are very helpful, but they are not perfect. Maybe plain udp can be > easier to grasp. The point is that you can use higher level semantics like pub-sub and then map them to physical transports depending on the actual location and granularity of your processes, nodes, threads, etc. For instance you can write a pub-sub event broadcast / collection layer that works across inproc:// for threads, pgm:// for large clouds, or udp:// for local networks or tcp:// for wide area networks. The code and patterns don't change when your location / granularity does. Further you can mix transports cleanly. If you can't see the benefits of this, in building truly scalable architectures, then you are simply not yet working at that challenge level. If you hand-code transports you are building knowledge of your scale and granularity into your code... it's of course doable, even *easy*. It's just utterly unscalable. Something like zbeacon is justifiable *only* because it is an abstraction that hides the fact it's using UDP. You could extend beaconing to work over other protocols, and we might do that. And then the real costs of socket programming, portability etc. Just take a look at zbeacon for this. To ask that application programmers should be aware that (to take one example) on OS/X you have to use SO_REUSEPORT, or to deal with the insanity that is Winsock... please... I thought we way were past this. 20 years ago I was hiding socket i/o in portability libraries like SFL[1]. -Pieter [1] https://github.com/imatix/Xitami-25/blob/master/sfl/sflsock.c _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
