Only hold a selection of WebSocket connections

[makkes]

Currently the signaling server keeps a WebSocket connection open to all peers in the network. This is not necessary and the number of client<->server connections should be kept at a minimum.

This implies adding a forward functionality to the router and probably should depend on our Chord implementation since the full mesh router would have to be adapted for loop prevention among other things.

[jure]

This is essentially the same as issue #4, so to keep it simple, I imagine this one can be closed.

[chris--]

I don't think this is same as #4 as the process of choosing bootstrap peers is independent of the DHT implementation. We need to discuss how to choose bootstrap peers. These peers ought to be relatively stable so the bootstrap procedure can complete. Approaches:

• Use some kind of metric (e.g. uptime) to determine stable peers
• ... suggestions?

[piranna]

Uptime info or other metrics should be shared between peers on bootstrap. How?

[jure]

I see, this is about bootstrapping then. Don't you only need one node though? About the metric, an interesting characteristic of the Kademlia protocol is that stable long-lived nodes will be at the top of buckets, which can be used for bootstrapping with multiple nodes.

http://xlattice.sourceforge.net/components/protocol/kademlia/specs.html#join

[chris--]

@piranna

Uptime info or other metrics should be shared between peers on bootstrap. How?

It does not need to be shared among the peers, rather it can be implemented as a functionality of the bootstrap server.

@jure

Don't you only need one node though?

In theory one node suffices but then that one must not fail (as the server cannot reconnect to another node).

[piranna]

I see... but this requires more logic on the server... :-/

[makkes]

@chris--

Use some kind of metric (e.g. uptime) to determine stable peers
... suggestions?

We could also implement an (optional) authentication mechanism for dedicated peers that are determined as bootstrap peers.