WebSockets in Play and Scala - Suggestion needed

[Joe San]

I'm not sure if this is the right forum to ask my question. I have a client that I wrote using Scala and the Play framework. It is a WebSocket client that creates a WebSocket connection and keeps it open to send about 20000 messages roughly in Json format. The server processes these messages and sends back Json responses. How is the WebSocket client supposed to handle the responses from the client? The server sends the responses asynchronously and the client registers a handler which in turn receives the messages from the server. Is the onMessage handler in the client called sequentially for each message that gets sent from the server? Any ideas?

[Ulf Dittmer]

I've never used WebSockets, so take this with a grain of salt, but I am quite sure that if either side sends 20K messages, there is a better architecture to do it. That does not sound like a scenario WebSockets are meant to address.

[Joe San]

Ulf Dittmer wrote:I've never used WebSockets, so take this with a grain of salt, but I am quite sure that if either side sends 20K messages, there is a better architecture to do it. That does not sound like a scenario WebSockets are meant to address.

What is that better architecture? I'm a bit curious to know about it! The motivation to use a WebSocket is that the client and server would require to exchange messages via TCP frequently and there is no bandwidth to create a new connection everytime. I'm just trying to apply load on the WebSocket connection and see how the server and the client behave under such conditions.

[Ulf Dittmer]

So you have not actually tried the scenario that you're worrying about, and it is just a test scenario to begin with?

The motivation to use a WebSocket is that ... there is no bandwidth to create a new connection everytime.

If there is a bandwidth issue then any communication will have problems. WebSockets are meant to address server-to-client communication (which generally is not possible with HTTP), and improve on latency (by not having to open a new connection for each message).

[Joe San]

Can you please throw some light on the other architecture that you were mentioning? That would probably give me some ideas!

[Ivano Pagano]

Ulf Dittmer wrote:If there is a bandwidth issue then any communication will have problems. WebSockets are meant to address server-to-client communication (which generally is not possible with HTTP), and improve on latency (by not having to open a new connection for each message).

There's more to that: the throughput of a websocket connection is a concrete improvement over the HTTP protocol, whose heavier payload (headers are sent with every communication) can become burdensome if you have a frequent exchange of small bits of content.
Joe's design could be the right solution, if the pure http scenario is verified as being too slow.

I too am curious about alternative designs.
Bye, Ivano

[Joe San]

The WebSocket end points proved valuable to us in achieving a better throughput. I like the idea and combining this with a non-blocking server like Netty is for me the way to go.