←back to thread

188 points ilove_banh_mi | 1 comments | | HN request time: 0s | source
Show context
bmitc ◴[] No.42170018[source]
Unrelated to this article, are there any reasons to use TCP/IP over WebSockets? The latter is such a clean, message-based interface that I don't see a reason to use TCP/IP.
replies(4): >>42170083 #>>42170086 #>>42170219 #>>42171211 #
tacitusarc ◴[] No.42170083[source]
Websockets is a layer on top of TCP/IP.
replies(1): >>42170167 #
bmitc ◴[] No.42170167[source]
Yes, I know that WebSockets layer over TCP/IP. But that both misses the point and is part of the point. The reason that I ask is that WebSockets seem to almost always be used in the context of web applications. TCP/IP still seems to dominate control communications between hardware. But why not WebSockets? Almost everyone ends up building a message framing protocol on top of TCP/IP, so why not just use WebSockets which has bi-directional message framing built-in? I'm just not seeing why WebSockets aren't as ubiquitous as TCP/IP and only seem to be relegated to web applications.
replies(3): >>42170288 #>>42170296 #>>42170305 #
j16sdiz ◴[] No.42170288[source]
WebSocket is fairly inefficient protocol. and it needs to deal with the upgrade from HTTP. and you still need to implement you app specific protocol. This is adding complexity without additional benefit

It make sense only if you have an websocket based stack and don't want to maintain a second protocol.

replies(2): >>42171569 #>>42175696 #
1. bmitc ◴[] No.42175696{3}[source]
> WebSocket is fairly inefficient protocol

In what way?

> This is adding complexity without additional benefit

I'm not sure that's a given. For example, WebSockets actually implement a message protocol. You have gauarantees that you sent or received the whole message. That may not be the case for TCP/IP, which is a byte streaming protocol.