websockets and session

[will]

Hi,

There's something I don't really get.

How to associate both websockets and sessions to push specific data to a specific client.

Let's imagine a private message system where people can send messages (stored in DB) to each other, each client having its own account. One client sends a message to another client.

The fact this user has sent a message could trigger the event "hey, you've received a message from this guy, click here to read it".

But how not to send this event to ALL connected clients ? And how to make it work so it could do "the user with ID 123 has sent (understand "has recorded inside a DB") the message with ID 666 to the user with ID 456 (you !!!), so let's broadcast to the websocket of the user 456 (you!!!) the event that the message 666 has been sent to him and is available for reading pointing to the URL http://domain/readmymessage?id=666".

Would it require to bind each websocket with user ID ? How to access to session data with websockets since playframework is stateless ?

Is it just even possible ?

I hope my question is clear enough dispite my rusty english

Thanks :)

[ngocdaothanh]

For a websocket request, there are 2 phases:
1. The websocket request comes in as a normal HTTP request, you have
everything like session data, cookie etc.
2. If you decide to accept (upgrade) the normal HTTP request, the
connection will be kept. Because there's phase 1, at phase 2 you have
everything you need.

I'm not familiar with the API of Play, but in Xitrum there's
"acceptWebSocket" method. If you decide to go to phase 2, you call
this method. Otherwise you treat the request as normal HTTP request,
e.g. you can send normal HTTP response to the client.

https://github.com/ngocdaothanh/xitrum-demos/blob/master/src/main/scala/demos/controller/WebSocketChat.scala
http://ngocdaothanh.github.com/xitrum/guide/async.html#websocket

On May 27, 12:52 am, will <william.bes...@gmail.com> wrote:
> Hi,
>
> There's something I don't really get.
>
> How to associate both websockets and sessions to push specific data to a
> specific client.
>
> Let's imagine a private message system where people can send messages
> (stored in DB) to each other, each client having its own account. One
> client sends a message to another client.
>
> The fact this user has sent a message could trigger the event "hey, you've
> received a message from this guy, click here to read it".
>

> But how *not* to send this event to ALL connected clients ? And how to make

> it work so it could do "the user with ID 123 has sent (understand "has
> recorded inside a DB") the message with ID 666 to the user with ID 456 (you
> !!!), so let's broadcast to the websocket of the user 456 (you!!!) the
> event that the message 666 has been sent to him and is available for

> reading pointing to the URLhttp://domain/readmymessage?id=666".

[biesior]

Te entire Http.context scope is not available in WebSocket action.

My solution that seems to work: while rendering new "chat window" for the user I'm genereting special encrypted key and passing it to the view.
In the view while creating websocket connection I pass the encrypted ID of the user to allow identifying the pair: ws connection - user and save it as an map.
When user A sends a message to user B I'm finding user's B ws connection id in the map and sending message there.

Sorry for laconic description, have no time currently do describe better, but think that can be helpful

BTW, check topic at SO,   http://stackoverflow.com/questions/10485205/how-can-i-authenticate-user-in-plays-2-0-websocket

[Nico]

@biesior: but if you use a Map to store your <clientId, websocket>, your app is no longer stateless, no ? It is a question that I still have...

[Alex North]

I don't believe your app can be truly stateless if your server can push data to clients over a websocket. It's clear that the server needs to maintain some state to know how to reach those clients.

[will]

That's what I thought : the websocket kills the stateless. Indeed the idea of assigning a hash to each client so you can interate on the map and retreive the client is the only working workaround, but....quite dirty to do...

Currently, websockets are not intended to work that way...

Thanks for your answers guys :)