SocketIo and the cloud

[Martin Kersten]

I have  a problem to understand how socket.io maintain contact in a single server / multi server environment.

Please help me clearify this:

1. Single Server: 

     Under the hood (fallback) its more like sending http requests in an efficient way towards a server. Since

     we use websockets we just overcome the limitation of only two life http connections to a server at a given time

     (is this rule still in place?).

   

     So in the end this comes down to http transport using simple http requests right?

2. Since http is a unreliable connection which only guarantees a single message is transmitted as a whole or not 

    (receiver knows if he gets all the content or not) the rest of the guarantees like timeliness, order etc. is missing.

    How does socket.io guarantees order? Does it buffer messages and attempt resends (didnt found much about this).

3. In a multi server environment, I have a server that deligates the load to some slave servers. Is the connection established

   towards the gate server (the one the DNS is pointing to) or is the answering server during the handshake used and 

   is the connection is established with the answering server thus doing something like cross domain scripting, or do 

   I completely lack a certain fancy new technology (I was off for some years doing only backend stuff).

4. On case of a reconnection attempt is the reconnect attempt made to any particular server (the old one) or is the 

    server the DNS points to is used.

5. If I want to listen to a particular server to establish something one might call a private conversation towards a particular

    server do i run into some cross domain protection stuff? I mean if i deliver a page and get the javascript socketio to

    connect to the serving server directly using a provided ip differing from the ip the dns is pointing to, do i have a 

    problem on that?

6. What happends if I want to use ports (ok those are limited) to identifiy my 'hidden' slave servers to just avoid cross domain

    scripting problems, do I get a problem with that one? (Just a theoretical question, I wont do this).

7. Whats engine.io. It claims to be a realtime engine. What does it mean? Whats the difference?

Cheers and thanks for your help,

Martin (Kersten),

Germany

[Elvio Rogelio Toccalino]

This should be very helpful. Specially if somebody with good understanding on how 0.9 and 1.0 clear each point. My mental model of the library code is built on client-only experience, so it might be incorrect. Either way, I'm sharing, if only to spur the conversation:

1) The websocket connection is negotiated through HTTP but, once both client and server agree to it, data travels back and forth through a point-to-point connection. This means the websocket _is not_ an HTTP connection, and so non of its limitations apply (e.g. maximum number, keep alive, CORS).

2) I was under the impression that the library kept a sequence number for packets. I went to the code but couldn't find a reference to that in the current releases... "maybe it got factored out to engine.io?", I thought. Checking engine.io master doesn't reveal any obvious sequencing. Neither do socket.io and socket.io-client in their 0.9 branches. Maybe I'm just crazy.
  I guess this means that, if your service cannot establish a websocket connection to the client, you get no guarantee on order of delivery.
  The other possibility is that, due to the fallback mechanism being based on a single connection polling, out of order packets are simply not possible. My brain requires a good argument (or community consensus) to gain confidence on fallback should that be the case.

3) This one bugged me a while back. My research led me to the (then) recent news that popular reverse proxy solutions were getting websocket support. This means now you can have a reverse proxy sit in front of your servers (each capable of establishing a websocket connection to clients), and clients can connect to the actual servers behind it. The proxy "passes on" the websocket.

4) The way I see it, in the event of reconnection the client is not guaranteed to end up connecting to the same server again (client code uses ``connect(origin/namespace)`` after all). If this is a problem, there are ways around it (apparently... I haven't had a need for any of them, this is just 4 months old research):
      * sticky sessions, to try to force the entire "client session" to happen with the same server.
      * client routing, which sends the same client to the same back-end server each time (thus ensuring reconnection to the same server)... think "client sharding". You could use the client's IP for this (or username, or whatever fits your domain better).
   Both this techniques are implemented on the proxy.

5) With a websocket connection, there are no cross-origin request restrictions. If your client has to fallback to a different transport, then your in trouble. There's always the Flash socket (ouch!).

6) I didn't get that. With any luck, the answers above should cover this point.

7) engine.io is a library designed to take on the task of abstracting the transport layer for realtime communications in a browser-server scenario. The code that solved that problem used to be a part of socket.io (and still is, in versions prior to 1.0) but was factored out to its own library due to it being non trivial... it turns out that a good transport layer is in itself quite hard to get right.
   A more practical explanation might be: with engine.io you can use an API akin to that of native websockets, but get reliability and scalability for free (it implements all the lower level goodies socket.io relies on).

I would very much appreciate any corrections on these subjects, as most of my knowledge on the innards of socket.io is built on hypothesis conjured during hacking sessions.

Regards,
Elvio.

2013/8/18 Martin Kersten <martin.k...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Socket.IO" group.
To unsubscribe from this group and stop receiving emails from it, send an email to socket_io+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.