Peer selection: prefer lower-latency channels where appropriate

[yyoon]

@asadovsky

I set up Syncbase for the Android Reader app (https://v.io/c/17230). The data synchronization works fine with multiple devices, but it takes about 1sec from a change made from one device to show up in another device. @kenashcraft once mentioned that not using the proxy improves the performance significantly, but we cannot turn it off because our Reader clients may not be in the same network.

My setup is:

• There is a stand-alone cloudsync peer which hosts the syncgroup.
• Each Android client initializes its own syncbase and joins the syncgroup hosted by the cloudsync.
• Changes are made to the syncbase tables, and changes are monitored using the watch API.

It would be nice if Syncbase peers could communicate via more direct channels where applicable.

[asadovsky]

Adding @rdvg and @hpucha It seems what we want here is for the devices to talk directly when they are on the same network, bypassing mounttable/proxies/etc. Bindu/Raja, to what degree is this addressed now that we've added discovery (with mdns) as a way to find peers? (Do we prefer local-network peers to other peers? For a given peer, do we prefer local-network RPC to mounttable-based RPC?)

[hpucha]

I have a prelim neighborhood aware selector that I am working on, that selects peers over the neighborhood when the mount table is not reachable.

If we feel confident that going over the neighborhood is actually low latency compared to going via the mount table, we can further enhance the peer selector.

[asadovsky]

Assigning to Bindu for tracking.