API for the number of client connections available

[sudheesh001]

Is there a way to use the API to get the connection map of clients or the total number of clients connected to a particular plugin? This would be really useful to have.

[simonrob]

At the moment, no (unless you extend the Better Together app itself and add your own methods for this, rather than writing a plugin).

Adding a way to get the number of connections is a fairly quick thing to do - I'll think about the best way of doing this and get back to you here. One immediate issue is that this number could easily get out of date if clients join or leave, so a callback would be required. I'm not keen to add more methods than are absolutely required for communication, so this would need to be optional for most plugins (e.g. something along the lines of addConnectionStateListener() or similar).

Could you explain a little more about what you'd want in a connection map of clients? I'm happy to discuss making clients individually addressable, rather than broadcasting all messages, but this would require careful design to avoid spoiling the current simplicity. I'd be interested to hear your thoughts.

[sudheesh001]

Currently for the game @am2990 and I are building involves that we maintain the list of connected peers so that during a message broadcast the intended recipient can only use the message and others discard in an effort to send a unicast message. Since unicast isn't available yet, we need to adopt the way of using from: and to: fields as a part of the message in sendMessage() digest.

In our case since every client needs the information of everyone in the network for the game to progress, since that's not available we have to go through a tiresome discovery protocol where the peers exchange DHT with their unique android IDs (and role in our case) which results in a continuous queries over the network.

Since the framework already has this information it'd be nice to expose the total number of connected client and APIs for clientJoin() and clientDisconnected() to update the DHTs accordingly in the plugins.

[simonrob]

If you had the ability to add a listener and receive updates when a client joined or left, would this be enough?

Are you currently handling this for individual activities in your plugin? E.g., if a client switches from one plugin activity to a different one (in the same plugin), should this trigger leave/join events?

[sudheesh001]

Yes that sounds perfect. We are currently handling this for individual activities in the plugin. If a client does switch from one plugin activity to another it should trigger leave/join events because the role(Activity) taken up by the client could be different and there might be cases where you do not want to have more than one client have a specific role.