Rework Addressing - Githubissues

muellmusik commented 10 years ago

This is a draft of a new addressing approach for comment and consideration. Sorry this has taken so long! Details:

Peer now spoofs a NetAddr
Add PeerGroup, an Array subclass with NetAddr send methods
Add ServerRegistry, a class which allows peers to share server info; both one per Peer and other configs
Add PeerGroupManager, a class for syncing groups of Peers or Servers
Add examples file for above

A few comments:

The complication with Server sharing was to make it generalizable. Basically ServerRegistry needed to know both the info for the shared servers, and the Peers it was sharing to. The current implementation aims to allow for both common cases (each Peer shares a local server with everyone else), and more exotic ones (e.g. 10 peers share 4 servers running on non-Peer machines). (I think there's one bug in ServerRegistry somewhere, but I'm out of time now, sorry, and wanted to make this public.)

PeerGroup ended up as an Array subclass. This means PeerGroups can be used in list patterns, and understand common collection methods. They can also spoof a NetAddr, as they understand sendMsg, sendBundle, etc. (In an initial version I had groups lazily resolved, but I think that is easily accomplished in other ways and would have made the implementation rather complicated.)

Examples:

~reg = ServerRegistry(~addrBook, 0); // set an appropriate client ID
~reg.addMyServer;
~gm = PeerGroupManager(~reg, '/serverGroups');

~gm.add(\us, [\scottw, \soctt]); // my laptop and test machine; use your own names

~reg.keys

Synth(\default, target:~reg[\soctt]) // pick a server

// we can use any method that Array understands, since PeerGroup is an Array subclass
Synth(\default, target:~gm[\us].choose)

// we can use any list pattern with a PeerGroup, since it is an Array
Pbind(\server, Pseq(~gm[\us], inf)).play

~addrBook.peers; // a PeerGroup with everybody
~addrBook.others; // a PeerGroup with everybody else
~addrBook.onlinePeers; // a PeerGroup with everybody currently online

With a combination of groups, array methods and list patterns, I think most of the Republic resolveWhere behaviour can be easily and concisely duplicated. The address by index from myself approach could be done with a custom pattern for example. If a \where key is needed I think that might be most cleanly done by either supplementing the default event or a custom event type, but I think it's probably possible to do everything simply without that.

To be resolved if this is to be merged:

Maybe Peer should be a NetAddr subclass rather than spoofing one
LocalNetAddr is no longer needed
PeerGroup has a 'name' instance var, but I don't think that's needed.
ServerRegistry could allow for sharing of ServerOptions as well
Some way of automating client ID.

The last one could possibly be a general reworking of the client ID approach. I would like the Bus and Buffer stuff (or something that makes the allocators work, anyway!) from Shared Server to be added to Common. It might be worth considering having scsynth itself provide clients with IDs. This would be much simpler than the current situation.

Signed-off-by: Scott Wilson i@scottwilson.ca

muellmusik commented 10 years ago

One further thought on this:

I suppose one may wish to have the option of shared groups or local only groups in different setups. That could be done pretty easily with this, but a slight adjustment would be to have groups stored in an AddrBook, and make PeerGroupManager more of a relay like class which just keeps groups in sync.

Semantically that seems nice, and keep with the a la carte approach.

muellmusik commented 10 years ago

One further thought on this:

I suppose one may wish to have the option of shared groups or local only groups in different setups. That could be done pretty easily with this, but a slight adjustment would be to have groups stored in an AddrBook, and make PeerGroupManager more of a relay like class which just keeps groups in sync.

Semantically that seems nice, and keep with the a la carte approach.

Ah, except I just remembered why I didn't do that! Having PeerGroupManager separate avoids a confusion between groups of peers and groups of servers, and allows you to have both. Sorry for the noise...

muellmusik commented 10 years ago

Sorry this branch has been left so long. Now finished some largish projects with BEER, so would be a good time to come back to this. There is one small conflict but should be easy to resolve.

The client ID and allocators stuff has been resolved in Common.

Any thoughts on this? Should we go ahead?

telephon commented 10 years ago

generally: definitely yes! I don't know what would change, I've reread this thread but I don't know what the current status is ...

muellmusik commented 10 years ago

Hi all, just a heads up that I intend to clean this up to resolve conflicts and finally merge. Let me know if anyone's terrified.

telephon commented 10 years ago

looking forward

muellmusik commented 10 years ago

Okay merged now. I'd kept in the AddrBook sendAll, sendAllBundle, and sendExcluding methods with a mind to deprecating them, as you can just use anAddrBook.peers.sendMsg, anAddrBook.others.sendMsg (very commonly useful), and could add anAddrBook.excluding(name).sendMsg to round it out.

But perhaps the existing methods are usefully lightweight, at least for backend stuff where you don't want to keep make a PeerGroup object all the time? Or maybe no big deal either way?

muellmusik / Utopia

Rework Addressing #4