2 ms·

Websocket does framing at the application layer, not the transport layer. Its probably more accurate to say that websocket lets you send binary or text messages

Websocket does framing at the application layer, not the transport layer. Its probably more accurate to say that websocket lets you send binary or text messages. More specifically this means that multiple WebSockets are not multiplexed over a single TCP/IP socket. One physical connection per-Websocket is a real scalability issue for servers and proxies. WebSocket-over-HTTP would address that. See the options being discussed here http://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-00#section-5.2 http://tools.ietf.org/html/draft-hirano-httpbis-websocket-ov...

Matthias247 12y ago
I don't think you would lose much in real world applications with the way websockets work: You want to multiplex websockets (for RPC) with normal HTTP requests -> Works through different URLs. If you want to multiplex different websocket RPC services on a single websocket endpoint it's easy to do this on application level with some kind of service identifiers. You will probably want those anyway for some purposes - even if your transport layer also provides multiplexing. Want to multiplex different websocket connections -> Works through different URLs. Yes, each will require a seperate IP connection. However I don't see a lot of applications that will go and utilize this scenario. They will either use gRpc OR WAMP OR SignalR OR etc, because that will make the maintainability much better then with a very mixed technology stack.
- louiscryan 12y ago
  Multiplexing RPCs onto a single WebSocket has some serious downsides. For one you now have an entirely custom protocol that standard proxies will not understand and cannot route. GRPC is very careful to be valid HTTP/2 for this reason. One of the major reasons for the existence of WebSocket is to support duplex streaming. HTTP/2 explicitly states "A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received" With better HTTP APIs (particularly in the browser) you would get full-duplex and the need for WebSocket would diminsh.

Matthias247 12y ago

I don't think you would lose much in real world applications with the way websockets work: You want to multiplex websockets (for RPC) with normal HTTP requests -> Works through different URLs. If you want to multiplex different websocket RPC services on a single websocket endpoint it's easy to do this on application level with some kind of service identifiers. You will probably want those anyway for some purposes - even if your transport layer also provides multiplexing. Want to multiplex different websocket connections -> Works through different URLs. Yes, each will require a seperate IP connection. However I don't see a lot of applications that will go and utilize this scenario. They will either use gRpc OR WAMP OR SignalR OR etc, because that will make the maintainability much better then with a very mixed technology stack.

louiscryan 12y ago
Multiplexing RPCs onto a single WebSocket has some serious downsides. For one you now have an entirely custom protocol that standard proxies will not understand and cannot route. GRPC is very careful to be valid HTTP/2 for this reason. One of the major reasons for the existence of WebSocket is to support duplex streaming. HTTP/2 explicitly states "A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received" With better HTTP APIs (particularly in the browser) you would get full-duplex and the need for WebSocket would diminsh.