Am 25.12.2013 um 14:16 schrieb Pieter Hintjens <[email protected]>: > 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.
It would indeed cover my paltry needs if we can get away without an API change once the UDP transport is slid in underneath that'd be really cool! - Michael > > What do you think? > > -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
