1

I am using Socket.IO with a MEAN stack and it's been excellent for low latency and bidirectional communication, but what would be the major draw back for using it for relatively static data as well as dynamic?

My assumption is that it would be more apt for sending more dynamic content. That being said, once a socket connection is established, how relevant is the amount of communication being done? Is there a time where it would be more appropriate to use http instead when a connection is constantly established throughout the user's direct interaction with the application?

Thanks!

eciice
  • 23
  • 3
  • 2
    "*sockets are traditionally limited to 6kb*" What? – alk Mar 15 '15 at 14:01
  • 1
    i have never used Socket.IO, but i guess it cannot profit that much from caching mechanisms as webservers do with static context. i do not really understand why you would want to use WS for static data at all. – Benni Mar 15 '15 at 14:12
  • that 6kb comment was in reference to http://stackoverflow.com/questions/14703627/websockets-protocol-vs-http, though after re-reading I see my mistake. – eciice Mar 15 '15 at 19:51

1 Answers1

3

WebSockets are a bidirectional data exchange within a HTTP connection. So the question is not if you use HTTP or WebSockets, because there is no WebSockets without HTTP. WebSockets are often confused with simple (BSD) sockets, but WebSockets are actually a socket-like layer inside a HTTP connection which is inside a TCP connection which uses "real" sockets. Or for anybody familiar with OSI layers: it as a layer 4 (transport) encapsulated inside layer 7 (application) and the main reason for doing it this strange way instead of using layer 4 directly is that plain sockets to ports outside of HTTP, SMTP and a few other protocols are no longer possible because of all the port blocking firewalls.

So the question should be more if you use simple HTTP or if you need to use WebSockets (inside HTTP).

  • With simple HTTP the client sends a request and the server sends the response back. The format is well defined and browser and server transparently support compression, caching and other optimizations. But this simple request-response pattern is limited, because there is no way to push data from server to client or to have a more (BSD) socket like behavior where both client and server can send any data at any time. There are various more or less good workarounds for this, like long polling.
  • WebSockets gives you a bidirectional communication, which makes it possible for the server to push data to the client or to send data in both directions at any time. And once the WebSocket connection is established by upgrading an existing HTTP connection the overhead for the data itself is very small, much smaller then with a full new HTTP request. While this sounds good you loose all the advantages of simple request-response HTTP like caching at the client or in proxies. And because client and server need resources to keep the underlying TCP connection open it needs more resources, which can be relevant for a busy server. Also, WebSockets might give you more trouble with middleboxes (like proxies or firewalls) then simple HTTP does.

In summary: if you don't need the advantages of WebSockets stay with simple request-response HTTP.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Thank you, that was enlightening. To put things into context, if I were establish a socket connection for one part of the application (let's say messaging between clients), would it make sense to use sockets in other places where I would be doing typical ajax calls given that the connection will persist throughout the entire user interaction? – eciice Mar 15 '15 at 19:52
  • If you would use the same WebSocket for the ajax calls too it could make sense. If you would use an additional one you need more resources at the server. If you do such calls in very short intervals it make sense again because you would need these resources anyway. In other words: it depends on what you are actually doing and how much resources you have and not on some abstract concepts. – Steffen Ullrich Mar 15 '15 at 23:19