-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Differentiation of upgraded connections #45
Comments
The 'handshaking' behavior accepts the original HttpRequest: All the magic for WebSocket is: Where, HandshakeRequest is an Object with def unapply(req: HttpRequest): Option[HandshakeState] method, so you can call it as: case websocket.HandshakeRequest(state) => Which means the returning state by: websocket.HandshakeRequest.unapply(req) |
Thanks @dcaoyuan. It took me a few days to get back to this and process your response. I am still not clear how to solve this. By the time the UHttp.Upgraded message is sent, the websocket.HandshakeRequest(state) is out of scope. We need the URI to compare against in the scope of the call to context.become() or it is not of much use. That doesn't seem to be possible in what you are proposing, the websocket.HandshakeRequest(state) is long gone by then. To make sure I am clear, what I am trying to achieve is that different businessLogic is selected based on the URI path that is being upgraded. if this is easier than I am making it out to be, would it be possible you could improve the example code to do this? Another option would be to create a PR against https://github.com/elasticmodules/demo if you feel that doing this in the mainline project example code is too much complexity. I just don't see how to do this without changes to the library itself. Thanks kindly, Brian |
bump |
@Topping We're a bit busy these days, will be back in 1 or 2 weeks. |
Ok thanks @dcaoyuan |
Brian, I took a different approach in order to make almost what you described. I use the standard route mechanism from Spray in order to "register" a specific handler actor through a generic WebSocketServerWorker started on each request, using the per-request actor pattern. You might want to take a look at my code at: Best regards, |
@Alain-Bearez: thanks! |
I am having a problem discovering how to differentiate connections that need upgrade. My intuition is the URI of the upgraded resource should provide the means to multiplex between multiple connections.
Because of the state machine architecture, this should be as simple as changing the businessLogic signature from Actor.Receive to a partial function accepting a path and returning an Actor.Receive. I took a stab at implementing it, but I can't find a good source for the request path. It seems to exist as late as https://github.com/topping/spray-websocket/blob/master/spray-websocket/src/main/scala/spray/can/websocket/WebSocketServerConnection.scala#L33-33, but beyond that, the path needs to be propagated. I could create a PR, but I'd imagine it could be improved on by @dcaoyuan so it may be a waste of time for both of us.
Thoughts?
The text was updated successfully, but these errors were encountered: