Jump to content
  • Advertisement
Sign in to follow this  
Razor89

How to keep a whiteboard in sync?

This topic is 3544 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everybody! I want to write a simple multiplayer whiteboard, similar to MS-Paint, because I want something to do with my friend over the internet and so far everything I've found is too simple, too complicated or too slow so I decided maybe I should write my own. The thing that perplexes me though is what would the best way to keep it in sync so that the server and client see the same thing? I figured maybe the client could send drawing commands to the server and await acknowledgement but I really can't see this working out too well. Also, naturally, I see UDP working out as the best protocol for something like this. Any suggestions would be appreciated.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
everything I've found is too simple, too complicated or too slow so I decided maybe I should write my own


Don't take this the wrong way; this is an honest question: If there are a number of solutions out there already, written by people who have presumably already studied the area, and you think they all are poor, what makes you think that you are more adept at writing this kind of software to get a better result? Especially given that you have to ask a question as basic as this?

Share this post


Link to post
Share on other sites
Quote:
so far everything I've found is too simple, too complicated or too slow
Have you had a look at DimDim?

[Edited by - CmpDev on January 9, 2009 3:30:12 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Quote:
everything I've found is too simple, too complicated or too slow so I decided maybe I should write my own


Don't take this the wrong way; this is an honest question: If there are a number of solutions out there already, written by people who have presumably already studied the area, and you think they all are poor, what makes you think that you are more adept at writing this kind of software to get a better result? Especially given that you have to ask a question as basic as this?


You raise a valid point but I thought it would be a valuable learning experience, and I'm not saying existing solutions are poor, or my result would be superior, but I want something really light weight and not over-complicated.
A large portion of my skills come from experimentation and hobby projects I do on the side.

I guess if there is something wrong with my ambition then I'll just cruise over to SourceForge and see if I can find something specific to my needs.

Share this post


Link to post
Share on other sites
Quote:
Original post by Razor89

You raise a valid point but I thought it would be a valuable learning experience, and I'm not saying existing solutions are poor, or my result would be superior, but I want something really light weight and not over-complicated.


There's a handful of front-end options, either Java or Flash. Going with fat client isn't really viable.

However, for a personal project, SVG + Ajax whiteboard would be my first thought, but it seems I'm late to the party.

This type of software is heavily UI-bound, and experience has shown that indie/OSS projects are sub-par in that respect. Commercial projects on the other hand will need to offer extensive and transparent integration of many more forms of collaboration.

When it comes to actual usefulness however, whiteboard alone is secondary, and more something that tacks onto full-fledged collaboration or communication infrastructure.

There are simply some types of applications which nowadays aren't worth re-inventing from scratch (Office tools) without extensive know-how and budget (Chrome, and still it's based on 50 or so existing projects), especially if they are a service which requires up-keep (whiteboard hosting server).

Anything UI-centric is problematic for hobby project, since value of such tools is in either a lot of attention to detail (behave Windows-like on Windows, Mac-like on Macs, know in which order buttons must be, how many pixels must be to the side of button, which shortcuts work, how to name the items, ...) or they require extensive and often tricky or hackish implementations (i18n comes to mind).

Either way, if I had to come up with something like this, I'd go with aforementioned front-ends, using authoritative host for matchmaking, while likely using Base64-encoded HTTP-compliant stream for communication.

Synchronization for such project isn't too important, the host merely needs to multiplex the incoming streams and relay them back, potentially storing past state for clients that join late.

Share this post


Link to post
Share on other sites
Quote:
Original post by Razor89
I guess if there is something wrong with my ambition then I'll just cruise over to SourceForge and see if I can find something specific to my needs.


There is nothing wrong with your ambition, that's not what hplus0603 was investigating. However, rather than just give you a solution, which he is more than capable of, he wants you to make sure that you really understand what you are trying to do before you actually do it.

Quote:
Also, naturally, I see UDP working out as the best protocol for something like this.


Let's take a few faqs from this forum's FAQ (courtesy of hplus0603) and see how they would work in with your project.

Quote:
Q3) Should I use TCP or UDP?
A3) There are at least four different kinds of games as far as networking is concerned: Turn-based games, Real Time Strategy games, Role Playing Games, and Action Games. Briefly, if you're turn-based, you should go with TCP because it's simpler, unless you need peer-to-peer NAT punch-through. For RTS games, you're usually best off using TCP, although UDP can make sense in extreme cases. For role playing games, the story is less clear -- action-based RPGs with lots of kinetics, like City of Heroes, use UDP, whereas slower RPGs and MUDs often stay with TCP. For action-based games like first-person shooters or racers, you should absolutely use UDP.


An online white board is closer in concept to a turn based game rather than an action based game. Think about real life, most of the time one person will write something, and then the other person will then take a turn. When more than one person are actively working on a white board, the audience will not be able to see all the changes at once (physical bodies in the way) as well as concentration issues (following more than one stream of writing at once). Because of this, TCP would be the better choice based on this faq, but let's consider a few others.

Quote:
Q4) If TCP makes sure the data gets to me without me needing to worry about it, why would I want to use UDP, which makes no such guarantees?
A4) TCP is a stream-based protocol. What goes in one end, will come out the other end, in order, with no duplication or packet drops. This is very convenient when correctness is paramount. However, to make this guarantee, TCP must suspend all packet delivery to the receiving end, if one packet is lost, until that packet can be detected as lost and re-sent. This may cause hick-ups of several seconds for a single packet that's lost!


Based on this FAQ, we can infer that TCP gets data to its destination in order, no packet drops, or duplications. In other words, it's accurate and reliable. The drawback though is when there is network congestion and packets start getting delayed. However, as we discussed in the previous faq, a whiteboard is more of a turn based design where "real time" action is not necessary. If packets are slightly delayed (we are talking about ms values mostly, not seconds) there will be no visible effects users will see.

Why? Because, if you have two white boards in physically different places, each viewer only knows that the other person wrote something when the data actually arrives. When it actually arrives is irrelevant (whiten a few seconds of reasonable delays I mean). As far as the other person is concerned, it's in real time and the other person just now "wrote" something.

Quote:
Q5) Is UDP faster than TCP?
A5) UDP uses slightly smaller headers per packet than TCP, which may give you marginally better throughput on narrow channels (such as modems). UDP will also deliver any received packet as it is received, without waiting to re-order packets, so if latency is more important than correctness of the underlying channel, then UDP will introduce less jitter in your game, and gameplay will be smoother.


This is more or less a nail in the coffin against UDP and your project. Latency is not more important in a whiteboard than the correctness of the data being received. The questions you asked in your project are all UDP architecture problems, not TCP. There are more FAQ points, but those are the three main ones that illustrate the case against your UDP view.

So, if you use TCP, you don't need to sync the client and server, data will always be accurate since it is not time based. No need for acknowledgments or worries about having to send the entire board state each update. In fact, you can even misuse TCP and treat each send/recv as a packet. You aren;t supposed to, but it "works" and it "works" well enough that an unthinkable high number of free mmorpgs use this approach, and they still function fine.

So, now all you will have to do is implement your packet protocol. Something like:

[XX] - Operation (256 total states possible)
[XX] - Payload size
[XX .. XX] Payload (variable length up to 256 bytes)


Then you can define your simple operations:

[01] - Set color
[03] - 3 bytes of colors
[RR GG BB] - Payload

[02] - Line
[04] - 4 bytes for location
[XX XX YY YY] - 65k x 65k max drawing area

[03] - Erase all
[00] - No data


And then you would have your simple whiteboard application. The server could just relay the commands to each client. To handle new users connecting, you can either maintain a global state on the server or just store all the commands and send them to the client. That will be up to you though, but having the server draw and send that state might be more efficient.

That's about it, most of your initial problems are solved with TCP and from there, you can concentrate on the actual client/server logic. Good luck!

Share this post


Link to post
Share on other sites
Thank you Drew, that is exactly type of help I was looking for.
Antheus, I am aiming for something desktop-oriented rather then web-based but thank you for your input.

At first I was thinking UDP based for real-time drawing, with a library like ENet, but if the commands are sent to the server and then the server processes it and sends the changes, or echos the commands back, to all connected clients then that would be ideal for TCP.

Share this post


Link to post
Share on other sites
Here's a sketch of how you could do it, assuming client/server:

1) The server keeps a "current sketch" (and possibly previous sketches, and multiple boards -- but keep it simple for now)

2) A "sketch" is a sequence of drawing commands, rather than a bitmap. Drawing commands might be "this text with this font at this location" or "this line strip in this width through these points" or "a square with these corner points and this color."

3) Develop a simple drawing program that can display lists of drawing commands, and has the UI to add more drawing commands (by using regular draw/paint tools). This can be single-user initially, as long as you clearly separate the document (list of commands), the UI (creating new commands) and the presentation (actually drawing a list of commands).

4) The job of the server is now three-fold:
a) gatekeeper for who may connect to a given whiteboard
b) keeping all previous commands, so that a new connection can be brought up to date
c) distributing new commands to other participants

The server does not need to know what the image looks like, only what the canonically ordered list of commands is!

Assign a participant ID to each participant. Tag each drawing command with the participant ID and a sequence number from the participant -- my first command is me:1, my second command is me:2, etc. Now, here's the only real "trick":

- When I add a new command, immediately add it as a "pending command" in the document. When rendering, render the entire list of commands, and after that, all pending commands. When you add a pending command, send that to the server.

- When you receive your own pending command back, you add it to the real list, and remove it from the temporary/pending list.

- You identify commands through participant ID and sequence number.

This will make sure that everybody keeps the list of commands in the same order (the order being whomever got their commands to the server in what order). This means that everybody will display the exact same image. If the different commands were in different order on different machines, then they would see different things (on your machine, circle A is on top of square B, but on my machine, they're reversed).

You can also allow modifications to existing commands, a la a typical drawing program; again, those modifications should be tagged in order, and held temporarily on the client until the server echoes it back.


So, what's hard about this? Well, mostly the "create a good drawing program" part. It's not the networking (given that you can do the simple thing above). It's not the messaging (given that serializing drawing commands is pretty easy). It's the UI. If you can first create a decent drawing program that's single-user, then you can probably turn it into a decent multi-user drawing program after that. However, history shows that writing a good UI is a lot of pain that most free/open projects simply don't want to go through. Compare Inkscape: It's a pretty good drawing program (when it doesn't crash), but the UI is not nearly as nice as that of Illustrator or Photoshop.

If what you want to do is learn how to create software, then by all means create software! That's the best way of learning! However, if all you want to do is to have a whiteboard to help you and your friends plan Warcraft raids or add comments when watching a shared Anime or something, then I would submit that it would be far easier to fix whatever is wrong with one of the existing lirbaries, rather than starting over from scratch.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!