2.x and 1.x compatibility

[niallel]

I know its not recommended, but it seems to work for the situation I'm in.

I'm using it with Cordova in an app, so I can't just upgrade the server as many clients will be on 1.x.
However I did a test with the client on 2.0.3 and the server on 1.7.4 and all worked.

Are there examples of what would work and what wouldn't. For example if I'm just using very basic ascii characters will it all work?

I've spent the day testing with my apps setup.
Everything has worked, 1.4.5 <--> 2.0.3 (client and server both ways).

When I read the notes for the utf encoding problem I see that it only mentions if you are using polling.
So I imagine if you are using web sockets then it works fine (seems to).
Is this correct, or am I missing something that could break it?

With the other issue #1058, it mentions if you are using the non-default namespace.
So again I imagine if you are using the default namespace it works fine (again seems to).
Is this correct as well?

Would someone be able to confirm if there are any other reasons why there would be problems.

thanks,

[IlyaDiallo]

+1

[jwalton]

Is there no way the 2.x client/server can detect they are connected to a 1.x server/client and use the old protocol? I'm in this same boat; I have thousands of clients connecting to my socket.io server, and they're all 1.x, so there's no easy way for me to upgrade to 2.x. I could perhaps spin up a second socket.io server on a different hostname and have my old clients connect to the old one and my new clients connect to my new one, but that sounds like a lot of work for something that should be handled by the library. :P

[niallel]

It does worry me that no one cares to comment. I realise that people might think there is some sort of liability associated, but a "sounds right, but can't commit" would be good.

In my case I went ahead and there were no problems, so I would imagine the only way to find out is to test it yourself. In my case everything worked fine, but it would make me sleep better at night if someone dared to answer my original question.

[jwalton]

It's becoming a more pressing problem, too, as the highest socket 1.x depends on libraries that are being tagged by nsp as having security vulnerabilites.

…

On Oct 14, 2017 14:02, "niallel" ***@***.***> wrote: It does worry me that no one cares to comment. I realise that people might think there is some sort of liability associated, but a "sounds right, but can't commit" would be good. In my case I went ahead and there were no problems, so I would imagine the only way to find out is to test it yourself. In my case everything worked fine, but it would make me sleep better at night if someone dared to answer my original question. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3007 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsF-zaEUlaF5op3yyIaVKD2jm0Hx2V7ks5ssPctgaJpZM4OZHX0> .

[IlyaDiallo]

Hi guys,
Same problem here. I've posted a question on SO, no answers (except my self-answer after testing).
I find it very strange that the socket.io devs are so careless about breaking compatibility and even documenting exactly what's broken or not, and how to cope. A lot of people are using that lib, right ?

[darrachequesne]

@IlyaDiallo please see the release note: https://github.com/socketio/socket.io/releases/tag/2.0.0

The release note contains the following breaking changes:

• a breaking change related to utf-8 encoding in engine.io-parser (Fix double utf8 encoding for payloads engine.io-parser#81)

As described in the pull request, strings were utf8-encoded twice when using polling transport, which caused issues with other client implementations. Basically, your application is concerned if you use strings where utf8.encode(utf8.encode(s)) != utf8.encode(s).

So, unless you only use websocket transport, or basic ASCII characters, that's an incompatible change.

• an update to make the socket id on the client match the id on the server-side (Add nsp prefix to socket.id socket.io-client#1058)

Example:

let client = io();
let adminClient = io('/admin');

client.on('connect', () => console.log(this.id)); // 6em3d4TJP8Et9EMNAAAA
adminClient.on('connect', () => console.log(this.id)); // /admin#6em3d4TJP8Et9EMNAAAA
// 1.x
adminClient.on('connect', () => console.log(this.id)); // 6em3d4TJP8Et9EMNAAAA

[niallel]

Thats great, confirms what I had tested.

[IlyaDiallo]

@darrachequesne I've read the release notes. They're not giving explicitly the informations that you are giving here, i.e. it only (partly) breaks polling transport, so you can mix 1.x and 2.0 versions with websocket transport (which is the protocol used in the vast majority of cases). I'd say that's important enough to be mentioned in the release notes.
For the #1058 issue, just to be sure, the question was:

So again I imagine if you are using the default namespace it works fine (again seems to).
Is this correct as well?

So that's correct, it only affects non-default namespaces ? And in that case, what are the symptoms ?

[jwalton]

@IlyaDiallo It sounds like the namespace is now incorporated into the client socket's id. So if you don't rely on that id, it won't affect you.

[IlyaDiallo]

@jwalton a you sure ? If it's only that (i.e. id is not used internally), that seems like a pretty weak incompatibility. More like "compatible with caveat" than a blunt "not compatible" statement.

[jwalton]

@IlyaDiallo This is the PR: https://github.com/socketio/socket.io-client/pull/1058/files.

[IlyaDiallo]

@jwalton I've seen the PR but I'm not familiar with the internals of socket.io, so I can't easily translate it to a yes/no response to the question "is the change affecting socket.io internally or is it only affecting users relying on the id being equal or not". And NB it's also related to #959 #2405 and #2509.
My point is that the exact compatibility issues could be much more easily and reliably documented by the people making the change than by others unfamiliar with the affected code.

[jwalton]

I too am unfamiliar with the code, so take my assertions with an appropriate grain of salt. :) But AFAIK, yes, it's just that the ID changed. The half of it with the polling transport is much more worrisome.