How does fallback work with socket.io?

Question

I'd like to use WebSocket with Java. Problem is, my server is separated from the client by a proxy that cannot be configured. I've been searching for implementations of WebSocket with fallbacks such as long-polling. I've found socket.io but don't know how the fallback works.

Under which case does it replace WebSocket and how?

Are there other libraries like socket.io with fallbacks implementations? I would like to find one in Java, but I only found Jetty.

EDIT: does the fallback only depend on the browser's compatibility with WebSocket? What if the cause of failure is a proxy badly configured, is socket.io going to detect it as a compatibilty failure and thus switch to long-polling (or another technique)?

Answer: since v1, socket.io includes engine.io, which brings the following features:

Phrygia

Answer 1

Socket.io is one of several implementations for the websockets protocol and its main selling point (IMO) is its ease of use: you don't need to code keep-alive mechanisms or decide which transport is best, it does it for you.

So, to make it clear, socket.io doesn't replace the websocket protocol, it's a package that implements it for you.

You mentioned long-polling. That is one of the transports used by socket.io. Long Polling is HTTP based and it's basically request --> wait --> response and the wait isn't very long, as it can be dropped by load balancers on EOF or stale connections. Nevertheless, it's still useful when the websockets protocol (TCP based) isn't available and socket.io automatically re-establishes the connection for you. Notice that websockets is a relatively new protocol, ratified in 2011, so older browsers don't support it. Well, socket.io detects that and then resorts to long polling, so you don't have to "worry" about it.

A websocket connection starts with HTTP, listening on the same port. For example, http://localhost:8080 (just a silly example). Then, when it's possible, socket.io switches to ws://localhost:8080 for you.

I never had problems with network topology challenges when using socket.io, as when the HTTP port is available and using long polling / websockets is possible, it just worked for me.

One of the libraries with fallback implementation, as you mentioned, is netty-socket.io. Notice how it configures the two transports:

public class Configuration {

    private ExceptionListener exceptionListener = new DefaultExceptionListener();

    private String context = "/socket.io";

    private List<Transport> transports = Arrays.asList(Transport.WEBSOCKET, Transport.POLLING);

    private int bossThreads = 0; // 0 = current_processors_amount * 2
    private int workerThreads = 0; // 0 = current_processors_amount * 2

The complete code can be found here.

Node JS has also libraries for websockets, and I mention it here just to clarify that long polling and websockets aren't the only two available transports (might be the only ones in Java):

io.set('transports', [                     // enable all transports (optional if you want flashsocket)
            'websocket'
          , 'flashsocket'
          , 'htmlfile'
          , 'xhr-polling'
          , 'jsonp-polling'
        ]);

In a nutshell, socket.io attempts to make things as easy as possible for you, including not having to worry about what transports to use, as it's done under the hood for you, yet still configurable if you want.

I hope this brief explanation helps you!

Assentor

It does, thanks a lot! Would you recommend netty-socket.io in a business environment? It seems consistent. The advantage would be the Java language, which easier to propose to the client and the developpers. Another question (added in OP), is the fallback only depending on the browser's compatibility with WebSocket? What if the cause of failure is a proxy badly configured, is socket.io going to detect it as a compatibilty failure and thus switch to long-polling (or another technique)? – Tiphanie

Yes, would be my answer to all of your questions. The fallback on socket.io works like black-magic: it starts with the best connection possible then it keeps downgrading until it fails. However, you either love this or hate it. I have co-workers who don't like this functionality: they want to code the fallback, keep alive (heart-beat) all by themselves. If that's the case, then, by all means, use engine.io, which is what socket.io is built upon. It all depends on how much you want to code yourself or rely on a tool. Personally, I love socket.io, but that's just my opinion. – Assentor

About Java: it uses thread pools for connections, which could be expensive on a massive scale. Notice that thread pools are basically time slicing features, not "real" threads (down to the CPU code). If your number of clients is huge, AND you're open to other tools, Node JS might be better suited for your case. Its architecture is asynchronous, non-blocking, single threaded. But this is off topic, as your question was about socket.io. I added this comment because you asked about Java. In a nutshell: you can do virtually anything on Java, but there are other tool choices out there. Good luck! – Assentor

This is a nice answer, but you could answer the question? The title skews stackover flow searches currently. The questions is, how? Is there configurations you need to do? Can we at least link to the docs where it has an example? – Handspring

@urasquirrel You can check out the socket.io docs for configuration options and see how it works. I couldn’t possibly include everything in my answer. Sorry about the search results, there’s nothing I can do about that. – Assentor

@Assentor I think the answer I was looking for is... it happens automatically under the hood, you don't have to do anything. Is this correct? If so I suppose you answered the question kind, but I feel that the question title would be better fit to say, "How does socket.io handle automatic fallback?" . The current title could be presumed to mean "What am I supposed to do to make auto fallback work.", but if socketio handles it on it's own without any extra work then... perhaps this title should change to be more explicit so that people aren't confused in the future. – Handspring

As of 2020, does it still make sense to implement web apps with long polling fallback mechanism or can we just stick only with the WebSocket protocol and be good to go? – Deformity

@tonix: it still makes sense. Some companies restrict ws connections so employees in those companies need sites that use a fallback. – Burdened