tree 7ae41c9d8b9cb72b5d4c5956e4fe9e45eaf9f3b3
parent 8d257ce386137a8e9df842a9993c1594866e2ba2
author Asim Shankar <ashankar@google.com> 1464839674 -0700
committer Asim Shankar <ashankar@google.com> 1464893106 +0000

services/syncbase: Export the NeighborConnectionTimeout

So that it can be used as an option to the RPC Server that is created to
host the syncbase service.

Without this change, the following could happen:

- Syncbase A and syncbase B discover each other
- Because both have internet connectivity, they have
  a connection to the proxy and an endpoint through it
- A and B invoke methods on each other through their
  proxied endpoints
- B loses internet connectivity (and correctly connects
  to A through some other means such as bluetooth)
- However, when A wants to invoke a method on B,
  it ends up trying to re-use the (defunct) proxied
  endpoint in its cache instead of the bluetooth
  connection.
As a result, changes in B would be propagated to A,
but not the reverse.

With this channel timeout being provided to the server,
A will determine (within 5 seconds) that the proxied
connection is defunct and it should try some other
endpoint instead.

RPC requests to multiple endpoints cannot be sent in
parallel in order to maintain "at most once" semantics
of an RPC invocation. It is possible that this is not
needed for the syncbase/GetDeltas use-case, but that
larger investigation is left as an excercise for the future.

MultiPart: 2/2
Change-Id: I9325162244cf86556ad2675811dce1b670dfbb48