Near-simultaneous actions (chat messages)

[Tobi Reif]

Hi

I'm searching for a framework for building a realtime web app.

I'm testing near-simultaneous actions (chat messages) in Meteor, Derby, etc.

I tried http://chat.derbyjs.com/lobby :

Opened the chat in a Firefox window and in a safari window. Wrote each message, entered in Firefox and then immediately entered in Safari - both messages got posted, but they had a different sequence in the chat history in each browser:
       
  In the Firefox window:
     "just a test 1"
     "just a test 2"
  In the Safari window:
    "just a test 2"
    "just a test 1"

Is this an issue that Derby has? Or Express? Or just the chat app?

Tobi

[greelgorke]

it's a feature. the changes in the client are updated immediately, there is no trip around to the server for this. i guess a  reload will show you same order of messages. 

[Tobi Reif]

It would be an issue in many use cases, consider the case where people
compete in a quiz and it's relevant who posted the correct answer first.

I need a framework that ensures the integrity of the central model (the
chat history), and ensures the correct synchronization of all the client
views.

Is the issue I described below inherent to Derby? Or is it something the
chat demo could resolve?

Potential issue:

User A enters a chat message (using browser/client A), the message
gets added to his view immediately, and it also gets sent to the
server. The server sends it to user/client B for update of his view.
But in the meantime user B enters a chat message, it gets added to his
view immediately - there now is message B as last message in user B's
chat history and message A as last message in user A's chat history.

Potential Solution (for certain types of web apps):

Don't have immediate client view updates.

Send the piece of data (which also is an update request) to the
server who adds it to the central model and distributes it to all
clients (incl the client of the user who created the piece of data).

Each client updates its model and view, then sends a short "I
processed the update request I got" to the server.

The server waits for the last such signal (ignoring any users who
disconnected), and then is ready for the next piece of data (the next
update request). If there are items in the queue, process those first.

This way, whichever data piece reaches the server first wins (and wins
on all clients), and the data piece that reached the server a bit
later will be processed after the first one has been reflected in each
client.

The above approach might be an option for web apps where the described
integrity is crucial (even though the approach would make the view
update in the creator's client a bit slower).

Tobi

[greelgorke]

this ones is in the doc: http://derbyjs.com/#conflict_resolution

the implementation of the chat- example may not meet your requirements directly. the chat itself isn't designed to be a distributed speed quiz contest. if you have this strict requirement, i guess you can develop your quiz app in derby as well i.E. be sorting the messages on server-side timestamps before presentation. in the chat example there is a simple Array.push that merged with use of techniques as documented. 

[Nate Smith]

Tobi,

We hear you that converging to a consistent state is important. This is something that Racer (the data layer under Derby) does actually do correctly, but we have some work to do to make Derby's DOM bindings properly reflect the underlying model state with certain race conditions.

As greelgorke pointed out, the immediate updating of the view is a feature of Derby, and it is also necessary to make offline clients work. Eventually the framework will take care of this, but I realize there are a few bugs at the moment. Feel free to file an issue on Github.

Thanks!
Nate