3 ms·
If you're not bound to a browser, what's the benefit of using WebSockets vs. something on top of normal sockets? Personally, I thought this was going to be a So
by mintplant 12y ago
If you're not bound to a browser, what's the benefit of using WebSockets vs. something on top of normal sockets? Personally, I thought this was going to be a Socket.IO server in C++.
- TazeTSchnitzel 12y agoThe benefit is you don't need a separate service for non-web clients. If you have something TCP-based, it's usable only by non-web clients. If you have something WebSocket-based, it's usable everywhere. Edit: An additional consideration: WebSocket is a nice, message-based protocol with easy-to-use APIs everywhere, unlike the stream-based TCP whose usual API (Berkeley sockets) is rather more difficult to use.
- hamidpalo 12y agoTCP is usable everywhere. Socket.io builds on top of websockets. Socket.io is useful when you have legacy web browsers that may not do websockets. Beyond that, it does not bring much over regular websockets.
- TazeTSchnitzel 12y ago> TCP is usable everywhere. Not on the web it isn't. I agree that socket.io offers little over WebSocket except for backwards-compatibility, but the OP's question was more about why you'd want to use WebSocket.
- rpcope1 12y agoI had the same gut feeling. TCP already seems like a fine enough abstraction (especially in comparison to UDP), and it is actually literally _everywhere_. Maybe someone should write a TCP socket implementation for the browser instead of trying to re-implement the transport layer on top of the application layer.
- alexchamberlain 12y agoBecause firewalls are really stupid, and can be fouled into believing your app is a web browser (which I guess it kind of is at that point).