share-primus questions

[Samy Alzahrani]

Hi,

In a previous post where share-primus was announced sharejs author expressed concerns regarding ordering of messages.

Is there any update in this regard?

If broswerchannel is used as the transport for primus, will this still be an issue ?

Thank you.

Samy

[Joseph Gentle]

It should be fine so long as messages stay ordered - browserchannel or
websockets both guarantee this.

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

[Samy Alzahrani]

What about other transports. Engine io for example?

You received this message because you are subscribed to a topic in the Google Groups "ShareJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sharejs/AE-M5GQndcY/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to sharejs+u...@googlegroups.com.

[Joseph Gentle]

I won't speculate on what guarantees engine.io does or does not
provide. I have no faith in Guillermo's ability to write reliable code
after being burned using it in sharejs a few years ago.

-J

[Dmitry]

Hi Joseph,

Maybe I'm missing something, so just checking. The client sends next OP only when it receives acknowledgement that previous OP was accepted by the server. What are the possible consequences with unordered messages? Can they actually happen in "real life"?

[Joseph Gentle]

If you're subscribed to a document that I'm editing, the server will send you operations in order (op 100 then op 101 then op 102). If the operations arrive out of order, the client will throw. I could buffer up the operations in the client and replay them when I have them all, but I'm not going to do that. That code is tricky to implement correctly (I know this from experience) and in my opinion its the responsibility of the data transport. The logic doesn't belong in ShareJS.

I'm also quietly convinced that there are other bugs in socket.io that will cause other issues. I've wasted days of engineering time tracking down obscure bugs in ShareJS, only to find that they're actually bugs in socket.io. For example, if a socket.io connection closes then reopens later (I sleep my laptop and wake it later on), what do you think happens? Last I checked, socketio emits an event telling you that the client is gone (so I flush all state related to that connection). When it comes back you simply get messages from a clientID which no longer exists. This crashed the ShareJS server (it was an obscure null reference that should be impossible, that I couldn't figure out how to reproduce). When I found out, I was shocked and appalled. Sockjs is better about this sort of thing but it still doesn't give you ordering guarantees.

By all means use a bad transport if you want. I won't judge you, but if you encounter obscure bugs I will ask you to switch to websockets or browserchannel and try to reproduce the problem before I waste my own time tracking it down. And I won't accept pull requests which add message ordering to ShareJS - it would only encourage more bug reports complaining about other socketio problems that I really can't do anything about.

As an aside, I get into these conversations every month or two. Most people I talk to who are building real realtime software in node have been burned by socketio as well, and I've shared a fair few war stories with them. I don't know anyone who runs socket.io in production, and I don't recommend you do either.

-J

[aslak hellesoy]

I have been thinking about building a small messaging library for node that would try to use WebSockets first and revert to Browserchannel if the client doesn't support it. It would be super thin.

Give me a heads up if you want to collaborate on this.

Aslak

[Joseph Gentle]

Sounds useful. I'll probably end up needing something like that here
at work, but I don't have time right now to collaborate on it. Please
ping me if you make something like that though - if its good, I'll use
it and otherwise I'll file a bunch of issues for you :)

-J

[aslak hellesoy]

On Mon, Mar 3, 2014 at 8:01 PM, Joseph Gentle <jos...@gmail.com> wrote:

It should be fine so long as messages stay ordered - browserchannel or
websockets both guarantee this.

That's the whole point - to provide a library that tries the best transport first (WebSockets) and falls back to the second best (Browserchannel). None of the other (broken) messaging libraries would be supported.

The goal would be to plug this into ShareJS (either as-is, or via share-primus).

Aslak

[aslak hellesoy]

On Wed, Mar 5, 2014 at 12:28 AM, aslak hellesoy <aslak.h...@gmail.com> wrote:

On Mon, Mar 3, 2014 at 8:01 PM, Joseph Gentle <jos...@gmail.com> wrote:

It should be fine so long as messages stay ordered - browserchannel or
websockets both guarantee this.

That's the whole point - to provide a library that tries the best transport first (WebSockets) and falls back to the second best (Browserchannel). None of the other (broken) messaging libraries would be supported.

The goal would be to plug this into ShareJS (either as-is, or via share-primus).

Oops - replied to the wrong message. This was meant to be a reply to your "Sounds useful" message :-)

[Dmitry]

Don't want to argue about anything here, just a personal observation. Socket.io indeed old and have bugs, moreover it have tons of bells and whistles that neither needed or don't work as expected (redis store for cluster for ex.). Right now we use a slightly modified version of engine.io in production together with own fork of etherpad lite for more than a year and haven't noticed any significant issues. Few were found, but they were obvious - like immediate issues in IE and were easy to fix ourselves. 

We choose engine.io because it implements "upgrade" strategy for connections, while most others (including sockjs) uses downgrade strategy. That is, there is fast xhr request first, and then client upgrades to websocket. This greatly decreases time to connect & display data for interactive apps (we can't embed initial data into the rendered page).

Browserchannel seems to have great optimisation by allowing sending auth & user data in first request, but it lacks of websocket support that is a bummer. 

[Joseph Gentle]

Sorry for jumping down your throat or making assumptions. I should
really get my rant out in a blog post. I'm kind of amazed you're using
engine.io in production - how are you finding it? Do you have just one
server, or are you running more than one server?

I agree about browserchannel's lack of websockets. For my own projects
I'm leaning toward simply doing:

if (window.WebSocket)
use websockets
else
use browserchannel

We're piping everything over HTTPS anyway, so caching proxies
shouldn't be a problem. The potentially bad cases will be versions of
firefox & chrome from around the time websockets was changing
frequently, but I hope they didn't unprefix websockets until the final
version. (Also ws will fallback to a previous spec if it needs to).
Also firefox for awhile apparently disconnected a websocket if you hit
escape.

-J

[Collin Miller]

"Also firefox for awhile apparently disconnected a websocket if you hit
escape."

I love computers :)

( I've done worse. )

[Dmitry]

We're running a cluster of servers with engine.io connections being balanced using "sticky" url token (that is generated on a client for each new session). It's around 20 running processes right now, each handling about to 800 sessions (we add/remove nodes to keep number below 1000)

As you said you don't want to write workarounds for ShareJS to handle out-of-order messages, I probably don't want to write workarounds for transport library to use if(websocket) { } else { }. That's why engine.io seems to be a best fit for now, at least I don't feel an urgent need to change one lib for another.