[nanomsg] Re: Broadcast protocol
- From: "Jason E. Aten" <j.e.aten@xxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Wed, 11 Sep 2013 09:30:43 -0700
I like the idea that BROADCAST could use multicast or udp.
The 'catchup' (#3) should be entirely optional, since it will be very
inefficient if the provider of the catchup data has to go back a long ways
to catch up the new joins to have 'current data'. rsync like differencing
would be very good here for efficiency.
On Wed, Sep 11, 2013 at 6:13 AM, Paul Colomiets <paul@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> I would like to propose a new protocol for nanomsg. I call it "broadcast"
> just so we have some name to discuss. Better name is appreciated.
>
>
> Overview
> --------------
>
> I may define the protocol with the following:
>
> 1. There are many watchers
>
> 2. Watcher subscribes to a channel at the start
>
> 3. When subscribing watcher gets current data on a channel
>
> 4. When channel data changes, all its watchers get new value
>
>
> Combination of pubsub and reqrep can't be used here, because when pubsub
> temporarily disconnects some updates can be lost.
>
>
> API
> -----
>
> There are two endpoints: WATCHER and BROADCASTER
>
> The WATCHER (pseudocode, probably python):
>
> sock = nn_socket(AF_SP, NN_WATCHER)
> sock.send("channel:foo") # subscription
> while True:
> print(sock.recv()) # receives updated value
>
> sock.send("channel:bar") # cancel's previous subscription
>
> The BROADCASTER:
>
> sock = nn_socket(AF_SP, NN_BROADCASTER)
> while True:
> sub = sock.recv() # get subscription request from watcher
> _literal, channel = sub.split(':')
> assert _literal == 'channel'
> sock.send(channel + '\0' + data[channel], 0)
>
> # probably in another thread
> data['foo'] = 'newvalue'
> sock.send('foo' + '\0' + 'newvalue', NN_BROADCAST)
>
> Important points are:
>
> 1. Request is different from the channel that watcher would be subscribed
> to
>
> 2. NN_BROADCAST flag says that message is not a reply but a broadcast
> message
>
>
> To keep message short I do not discuss all the apparent issues, just
> asking for general agreement.
>
>
> Thoughts?
>
>
> P.S.: This protocol is result of discussion of the name service. I hope we
> will return back through the "monitoring data -> name service -> broadcast
> proto" chain shortly :)
>
> --
> Paul
>
Other related posts:
