[ANN] Primus support for ShareJS
aslak hellesoy
Victor Hooi
also mentions this:
Messages will arrive in order
aslak hellesoy
Hi,I'm not sure if this is true/relevant, but I read elsewhere that part of the reason for using BrowserChannel as the default transport was that it guarantees messages arrive in order?The README:also mentions this:
Messages will arrive in order
Cheers,Victor
On Wednesday, 8 January 2014 17:32:20 UTC+11, Aslak Hellesøy wrote:Hi all,A lot of people (myself included) want to use ShareJS with other transports than BrowserChannel. BrowserChannel is great, but there are several scenarios where WebSockets are more appropriate, or even other transports like SockJS, Engine.IO etc.Primus[1] is a facade around all these (including BrowserChannel) that provides:* A uniform Node-compatible Stream API for all of them* Fixes some browser quirks* Has great plugins like Substream [2]No changes whatsoever are required in ShareJS to make this work. All you need is Share-Primus[3].I would be happy to transfer the Share-Primus repo to the "share" GitHub organisation if Joseph is OK with it.Please take it for a spin, kick the tyres and all that.Aslak
--
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.
3rd-Eden
Hi all,
I’m the creator of Primus and contributor of various of real-time frameworks, I might be able to shed some light on this issue here.
It is true that Engine.IO, Socket.IO and SockJS do not guarantee the order of messages. This is only true for polling transports and not WebSockets and Flashsockets as they use one single TCP connection for communication and TCP takes care of the message ordering.
The problem with polling transports is that you COULD have 2 POST requests hit the server and that second POST request is processed before first POST request. The delay of messages has to be caused at the network or OS level in order for this to happen as Node.js it handles events and messages in the order that they are received. (I have personally not seen this happen before)
Browserchannel solves this by sending an id with each message that is incremented. The server or the client buffers the messages, checks if they follow their last known id and processes/or buffers it. If it was already known, the message would be dropped.
Now the best part here is that Primus has a great plugin system that gives you the ability to transform incoming and outgoing messages. If you want to guarantee message ordering across all transformers and it’s used transports you can simply create a small plugin that does the same as browser channel does and that is adding a message id to each outgoing message and buffer them when they come in.
Anyways I hope this helps,
Arnout / 3rd-Eden
Op woensdag 8 januari 2014 07:32:20 UTC+1 schreef Aslak Hellesøy:
Joseph Gentle
in-order delivery of messages. Its no good if their standard
transports guarantee in-order delivery but their fallback transports
don't - this *will* be the source of obscure, hard to reproduce bugs.
I don't care what transport you use with sharejs. I only wrote
node-browserchannel because I spent nearly 3 months of my life trying
to use all of the alternatives at the time and they were all
inadequate. Be warned that if you use a transport that doesn't
guarantee in-order message delivery, you will experience bugs that I
won't be able to fix.
To that end, ShareJS 0.7 has no dependancy on browserchannel or any
other transport. As a user of sharejs, the connection is officially
your problem now. You have to do a little more work as a result - in
the client, you have to give it a websocket-like object (this is
currently a little buggy but I'm working on it) and on the server you
give it a stream.
Here I've wrapped browserchannel for the server:
https://github.com/share/ShareJS/blob/master/prototype/server.coffee#L32-L58
.. And on the client its much simpler:
https://github.com/share/ShareJS/blob/master/prototype/public/index.html#L19-L21
Real websockets are better and they make sharejs much faster. They are
also pretty well supported in modern browsers now too. The only
notable laggard is IE which added them in IE10:
http://caniuse.com/websockets
Sorry for the delayed response - I hope that helps.
-J