On Wed, Dec 25, 2013 at 1:44 PM, Michael Haberler <[email protected]> wrote:
> rationale for the UDP unicast send/receive pattern: > my application scenario: > This suggests a 'query broadcast', followed by 'reply unicast' sequence is > the 'minimal noise' solution; there is no need for permanent broadcasting of > service descriptions ala zbeacon. OK, thanks for explaining this, it's clear. It's the same use case I addressed in my old UDP virtual transport for ZMQ (the VTX project). Broadcast request, unicast reply. The challenge is that UDP replies can get easily lost. If we had a udp:// transport, this would fit to a pub-sub (subscribe to multicast address, send to multicast address) plus a request-reply (acknowledged reply). As it is we can make this using a mix of zbeacon for requests, and UDP unicast + retries for replies. My proposal is to hide the fact we don't have a udp:// transport, and build a zservice class that provides explicit service announcement and discovery. Eventually we can expand this to other transports. zservice would build on zbeacon, though it has a different use case, and we can make this clear in the man pages. Beaconing is for dynamic networks where discovery is the same problem as presence, solved by heartbeating, and where TCP heartbeating does not scale. Service discovery is for more static networks where multiple hosts may provide a service. If you like this, I'll build a skeleton for zservice and see if the metaphor holds. What do you think? -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
