2 ms·

Great work thanks fir sharing! One decision that I don't agree on is the choice to send messages in order. I usually prefer to flood the client of messages an

by siscia 10y ago

Great work thanks fir sharing! One decision that I don't agree on is the choice to send messages in order. I usually prefer to flood the client of messages and attach at each message a timestamp (a monotonic increasing integer) and having the client to re-order everything. It is cheaper from the server point of view and the worked is done by the clients. Are there any reason why you picked your specific solution? Just a technical question, that I am very curious about. I guess that there are concerns that I am overlooking at the moment...

josephg 10y ago
That would work, but I don't think it would make anything simpler. You would essentially be reimplementing parts of TCP on top of whatever unordered protocol you'd use to make sure your client view is eventually consistent. All the APIs I used strictly order messages. Websockets simply don't have a UDP-equivalent, unless you want to send the events over plain long-polled HTTP requests or something, but that sounds like an inefficient recipe for disaster. And if you did that the client would need to be able to track and fetch lost messages. That adds client complexity and server complexity for the extra endpoints. My imagination is haunted by premonitions of bugs. In one ghostly image I see edits getting silently lost sometimes and not knowing why. Just, sometimes if I draw a line, on your screen you see the occasional block missing until you refresh your browser. In another premonition I imagine a packet reordering system thinking its missing a single operation and waiting on it forever. To the user it looks like everything has frozen completely. We have well-implemented protocols that deliver messages in order. I see no reason not to use them.
- siscia 10y ago
  Definitely, mine was just a simple question on the design, it is interesting to see how different people thinks ;-) The work to keep everything in order, definitely, has to be done somewhere. You are doing it twice, once sending the messages actually in order, another in the TCP stack. Clearly the one on the TCP stack "comes from free" for anybody reasonable. Like yours, also my mind is haunted by possible bugs, however in this cases I prefer to borrow from the Erlang philosophy and embrace possible failure. The way I model this problem is that the packets arrives usually in the same order, or one close enough, to the order in which they are send. It is rare that a single packet get lost, but if this happen I want to be able to reask for it and don't block the whole rendering. I would have accept to receive messages slightly out of order and have a guarantee of something like the last 10/20 messages. Would it require some reimplementation of the TCP stack? For sure! Would it be the common case? Definitely not! Would it make the architecture more resilient? I believe so but I may be wrong. Now, to be clear, your work is amazing! I am really glad that you shared it and it I a pleasure to have this kind of technical conversation. Given your technical and time constraints I would have done just the same. Just wondering if you have any thoughts on my counter points. Happy Easter!

by siscia 10y ago

josephg 10y ago

That would work, but I don't think it would make anything simpler. You would essentially be reimplementing parts of TCP on top of whatever unordered protocol you'd use to make sure your client view is eventually consistent. All the APIs I used strictly order messages. Websockets simply don't have a UDP-equivalent, unless you want to send the events over plain long-polled HTTP requests or something, but that sounds like an inefficient recipe for disaster. And if you did that the client would need to be able to track and fetch lost messages. That adds client complexity and server complexity for the extra endpoints. My imagination is haunted by premonitions of bugs. In one ghostly image I see edits getting silently lost sometimes and not knowing why. Just, sometimes if I draw a line, on your screen you see the occasional block missing until you refresh your browser. In another premonition I imagine a packet reordering system thinking its missing a single operation and waiting on it forever. To the user it looks like everything has frozen completely. We have well-implemented protocols that deliver messages in order. I see no reason not to use them.

siscia 10y ago
Definitely, mine was just a simple question on the design, it is interesting to see how different people thinks ;-) The work to keep everything in order, definitely, has to be done somewhere. You are doing it twice, once sending the messages actually in order, another in the TCP stack. Clearly the one on the TCP stack "comes from free" for anybody reasonable. Like yours, also my mind is haunted by possible bugs, however in this cases I prefer to borrow from the Erlang philosophy and embrace possible failure. The way I model this problem is that the packets arrives usually in the same order, or one close enough, to the order in which they are send. It is rare that a single packet get lost, but if this happen I want to be able to reask for it and don't block the whole rendering. I would have accept to receive messages slightly out of order and have a guarantee of something like the last 10/20 messages. Would it require some reimplementation of the TCP stack? For sure! Would it be the common case? Definitely not! Would it make the architecture more resilient? I believe so but I may be wrong. Now, to be clear, your work is amazing! I am really glad that you shared it and it I a pleasure to have this kind of technical conversation. Given your technical and time constraints I would have done just the same. Just wondering if you have any thoughts on my counter points. Happy Easter!