Closed domob1812 closed 5 years ago
The main off-chain broadcast class will forward messages to send to an abstract function SendMessage
(after encoding them to a string). Concrete implementations of a broadcasting system need to provide that function.
For receiving messages, things are a bit more complex, since we need to deal with waiting for incoming messages. Here, the class will provide a FeedMessage
function, which will decode a received string and process it (i.e. pass to ChannelManager
). We will also have Start
and Stop
functions.
Implementations that have their own receiving loop can then simply override Start
and Stop
, and pass received messages to FeedMessage
. However, we will also have a default implementation of Start
and Stop
, which will just start a thread repeatedly calling another function GetMessage
. So implementations without their own event loop can then simply override GetMessage
instead, which will block for a new message and return it.
Once the basic framework is done, we will implement a broadcast system that works by sending HTTP requests to a central server. The server will be implemented in Python. This can then be used already (e.g. with a shared public server and the ability for people to run their own if they want), and it will also be handy for Python-based integration tests.
For game channels, we need a system to handle the real-time communication (i.e. broadcasting moves among all channel participants). This should be done based on a generic interface, which is used by the
ChannelManager
to send moves and which can feed received moves back to it.For basic testing, we should also at least implement a "real" variant, which could be based on some TCP, HTTP or RPC server. Ultimately we also want an implementation based on XMPP, but that is something for later (not this issue).