简体   繁体   中英

Dispatch websocket connections based on subprotocol

is it technically possible to run multiple websocket servers that listen on the same port and dispatch using the subprotocol name ? Eg a process that would handle "protocol1" and another that would handle "protocol2". My guess is that it is not, since TCP cannot conditionally accept a connection, so the only way would be some kind of socket ownership transfer.

Actually, it would be possible to achieve by using a Proxy as a load balancer, which isn't something I tried managing before... So I can't post a demo configuration file.

I know Apache will allow you to decide on a proxy path according to the request headers - this means you can check the sub protocol before forwarding the data... But this is mostly a conceptual solution I never tested.

This question is tagged WebSocket++, so I will answer from the context of that library.

Maybe, depending on exactly what you mean. WebSocket++ will let you build one program that can internally handle multiple subprotocols. WebSocket++ has a pre-acceptance hook called the validate handler. In the validate handler you are presented with a list of subprotocols the client has requested and may choose which one you want to accept (or none if your server doesn't support any).

This isn't the same as conditionally accepting the TCP connection itself, but does let you conditionally accept the WebSocket connection. Once accepted your app can inspect the selected subprotocol in the open handler and choose which logic to use to process the connection.

A WebSocket++ based program can juggle multiple connections on multiple subprotocols simultaneously. If you truly want multiple independent processes handling each then the best WebSocket++ will be able to do is act as a proxy for those connections.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM