Is your feature request related to a problem? Please describe.
Once we set up web-based games (even just connecting to localhost) we need an implementation of client/server communication and updating the client when server-side communication changes. So far it looks like viable options are Poll-based ("anything changed? -> nope") and Pub/Sub ("subscribe gameid xyz -> ack" "publish gameid xyz -> ack"). Possible framework for Pub/Sub is the MQTT protocol, implemented by multiple servers (ActiveMQ, MQTT.js, moquette, https://mqtt.org/getting-started/, mosquitto). It's unclear how exactly Pub/Sub applies: our use case isn't exactly client-to-client like Pub/Sub seems to enable. Our clients will be publishing but the server broker won't be relaying that, rather updating context on the backend and publishing new state.
Maybe we could implement our own Pub/Sub, but seems like a lot of work.
There's also persistent connection socket frameworks, where clients need to be connected. we could use that as a "while on, use socket. else in background poll every 30 minutes." for a mobile app example. in web client simply having it open maintains a persistent connection.
Client could also react to ServerSentEvents, which may need a custom implementation in Java.
https://engineering.linkedin.com/blog/2016/10/instant-messaging-at-linkedin--scaling-to-hundreds-of-thousands-
Might be over-optimizing though.. perhaps we start with a poll-based architecture and abstract it behind a communication engine interface that implements a well-understood API (a proxy between what may be an MQTT broken or plain webserver) and translates to Actions handled by the game engine itself.
This can be abstracted by a communication protocol. The initialization for the jar creates a communicationProtocol based on configuration (only when in --server mode) and passes that protocol an instance of the engine.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
Once we set up web-based games (even just connecting to localhost) we need an implementation of client/server communication and updating the client when server-side communication changes. So far it looks like viable options are Poll-based ("anything changed? -> nope") and Pub/Sub ("subscribe gameid xyz -> ack" "publish gameid xyz -> ack"). Possible framework for Pub/Sub is the MQTT protocol, implemented by multiple servers (ActiveMQ, MQTT.js, moquette, https://mqtt.org/getting-started/, mosquitto). It's unclear how exactly Pub/Sub applies: our use case isn't exactly client-to-client like Pub/Sub seems to enable. Our clients will be publishing but the server broker won't be relaying that, rather updating context on the backend and publishing new state.
Maybe we could implement our own Pub/Sub, but seems like a lot of work.
There's also persistent connection socket frameworks, where clients need to be connected. we could use that as a "while on, use socket. else in background poll every 30 minutes." for a mobile app example. in web client simply having it open maintains a persistent connection.
Client could also react to ServerSentEvents, which may need a custom implementation in Java.
https://engineering.linkedin.com/blog/2016/10/instant-messaging-at-linkedin--scaling-to-hundreds-of-thousands-
Might be over-optimizing though.. perhaps we start with a poll-based architecture and abstract it behind a communication engine interface that implements a well-understood API (a proxy between what may be an MQTT broken or plain webserver) and translates to Actions handled by the game engine itself.
This can be abstracted by a communication protocol. The initialization for the jar creates a communicationProtocol based on configuration (only when in
--servermode) and passes that protocol an instance of the engine.Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.