I'm not sure what you are replying to as it's been redacted, but just wanted to say that there's really nothing wrong with that technique. Developers tend to way overestimate the cost of a long polling request with minimal headers.
Also the speed benefit of websockets over long polling is so trivial that it doesn't really matter.
A couple of posts were deleted on this thread, perhaps because the authors realized they were mistaken. The claim was that long-polling and WebSockets are bi-directional in the same sense, and mine was that one type of bi-directionality is simulated and has real limitations.
It doesn't matter if the overhead is low: with long-polling, the server can't send a waiting message until the client requests them. With true sockets, the server can send messages as soon as they are available.
Comments
I'm not sure what you are replying to as it's been redacted, but just wanted to say that there's really nothing wrong with that technique. Developers tend to way overestimate the cost of a long polling request with minimal headers.
Also the speed benefit of websockets over long polling is so trivial that it doesn't really matter.
I could not agree more with this comment.
A couple of posts were deleted on this thread, perhaps because the authors realized they were mistaken. The claim was that long-polling and WebSockets are bi-directional in the same sense, and mine was that one type of bi-directionality is simulated and has real limitations.
It doesn't matter if the overhead is low: with long-polling, the server can't send a waiting message until the client requests them. With true sockets, the server can send messages as soon as they are available.