My service already uses Websockets to communicate with an HTML5 in-browser client. The client is served by the same server from a normal http request.
Now I would like to offer the same service/app but out of the browser, and I would like to offer it over TCP sockets.
The RPCs/action object I am using are going to be the same, the serialization is going to be the same, the logic is the same. I just want to use TCP socket instead of WebSocket.
I would like to keep the code together under the same "project folder", starting all at once when I deploy the playframework server (basically on start I want to start listening to WebSockets, TCP sockets and http requests), and have everything in the same package on deploy.
I know that:
- It is not necessary, since WebSocket can be used in not-in-browser apps, but consider this an exercise or a curiosity question.
- playframework is built on top of netty, and I used netty before to do some TCP services (nothing big and nothing prod ready though ... so not an expert). So they should work together right?
What I was thinking to do:
- Have an akka actor listen for new socket connections.
- Wrap the connections (WS or TCP sockets) into a
ClientConnectionManagerinstance - Pass it to the actors that takes care of the connections/rpc logic.
Other leads I considered: Reimplementing the playframework Controller class.
Or is there an already implemented solution for this?
