5

Imagine a multiplayer whiteboard where several people can draw at the same time. To keep it simple, lets say there's a single object on the whiteboard which can be moved or deleted by any user. There is no notion of user-owned objects (i.e. it's important that any user be allowed to manipulate any object... it's a free-for-all whiteboard)

My problem is this... if two users try to do a different action on the object at the same time, i.e. one deletes it the other moves it, what happens?

Right now- in just letting the messages go through, it gets all out of whack.

One idea was to have a serverside control which resolves who has control of the object, and nothing is allowed to happen clientside until that conflict is resolved. Conflict resolution can be based on a first-come, first-serve basis.

Even though this can happen very fast, the small delay (~50-300ms) is unacceptable since movement must be instantaneous on the client side. For example, instead of manipulating objects, think of a pen. For there to be a delay till they've already started drawing... not good!

Another idea was to have a "request control" button, which asks the serverside extension for control.... same idea as before, but now they aren't frustrated by the initial delay of pen drawing. This is also not so good though since they must hit that button till they can do anything, and this whiteboard is really meant for kids...

Any other solutions? :)

davidkomer
  • 3,020
  • 2
  • 23
  • 58

3 Answers3

3

This is an interesting problem is typically solved via a combination on client and server side resolutions. If you are familiar with WoW, especially the initial release days, you will remember a server crashing and everyone continues to move. This is done by the client managing predicative movements, and requesting periodic updates from the server for the actual location and behavior values.

A similar idea should be applicable to your problem. Your server-side resolution on a f.c.f.s basis seems ideal. The issue as you mentioned is latency reducing the user experience. To do do away with this, why not give the user full client-side control, and then request the update from the server after the operation? So if you move a circle down 200px, and I change the color to green, we can both see instant client side behavior, but when you release the circle you will also see it turn green, as told to do so via the server.

The obvious issue to this becomes when both users change the same properties of the object. At this point, the f.c.f.s system will need to make a decisions regarding what to do based on client use. Should it perform the net delta on the object? Should you notify the user that another user has changed the object in a different manner? This is more of a feature question than a technical one.

Ben Roux
  • 7,308
  • 1
  • 18
  • 21
  • I like how you've pointed out that the conflict only exists for specific property changes! i.e. color and position are not a conflict, but position and position or position and delete are... – davidkomer Jun 05 '11 at 09:44
  • I guess only the simplest level, I could maintain a history and "jump back and prohibit control" if the server gives a message of object-locked... – davidkomer Jun 05 '11 at 09:46
  • a simple conflict resolution with similar property manipulation would be timestamping user interaction and maintaining the latest change (or if object is deleted just keep it deleted) – dain Jun 05 '11 at 13:57
0

Really interesting question! The state of whiteboard is stored on server (e.g. in DB). There's 3 possible actions on client: startEditing, finishEditing, delete. Just after some action is performed you should send a message to server to describe an action.

If startEditing is sent, first of all you should check if the object you are going to edit has no lock. If it's unlocked, you should put lock (the lock should contain information about the user who put the lock). Then you should send message to all active clients to tell that that object should not be edited.

If finishEditing (this one should contain information about changes in object) is sent you should change the object in DB release the lock and send message to all active clients telling about the changes and released lock.

If delete is sent. If the object is not locked by client different from that one which sent the message, you should delete the object from DB and send message to all active clients ordering to delete that object from whiteboard

Eugeny89
  • 3,797
  • 7
  • 51
  • 98
  • The problem is that when startEditing is sent, the "check" requires a check serverside, which introduces delay – davidkomer Jun 05 '11 at 10:06
  • If the first client sends `startEditing` in the same time as second, some of clients will be the first to put lock, and the second will see the lock, and do nothing – Eugeny89 Jun 05 '11 at 10:28
  • yes, but again- the problem is that the client must immediately be able to draw if it will have the lock. – davidkomer Jun 05 '11 at 12:44
  • In other words.... Client1 and Client2 each attempt to draw Client1 gets to the lock first, and gets permission from the server. Only now can Client1 actually draw- so there is delay between when Client1 pressed the mouse and received permission – davidkomer Jun 05 '11 at 12:46
  • And what about proposed sending message to all active clients that object is locked just after server recives `startEditing` message? You will know whether to allow or to deny drawing without delay – Eugeny89 Jun 05 '11 at 15:14
0

You might be able to do something where you show the local items interactions and what ever one else is seeing. At the start you show something like, the transparent object your are interacting with or writing with is not final, everyone is seeing the opaque objects/drawings are final and what ever one sees.

When you detect 2 users moving an item at the same time, on their own screen they are both transparent, in the course of some multiplayer updates the user that has been determined to have control is still moving the object, and you can show some kind of event (maybe a generic poof) of the user that was moving their object that has now been determined to not be in their control.

this way you get immediate drawing response and a bit of frustration from time to time when they are determined not to be the one in control of an item.

gltovar
  • 463
  • 4
  • 10
  • If I'm understanding you correctly, it's the same idea as what I said above- "I guess only the simplest level, I could maintain a history and "jump back and prohibit control" if the server gives a message of object-locked... " BUT you've added a visual cue on the client side so they can differentiate between an object that has actually move vs. a possibly-temporary attempted move... ? Is that right? I like it! – davidkomer Jun 09 '11 at 06:08