0
\$\begingroup\$

I'm making a collaborative whiteboard app so that when someone is drawing and uses a rectangle for example, a rectangle packet is sent to the server with parameters like x, y, width, height, color and then that packet is sent to everyone else in the room so that a rectangle is drawn on their screen.

So far everything works perfectly and there's also a stack on each client of all the commands thus far for infinite undo and redo. However, there server does not contain this stack because all it has to do is forward commands to clients in the room.

Everything is working perfectly so far and everyone can see everyone else drawing in real time but I'd like to implement a feature where if someone joins a room late they can see the current whiteboard. That is, the entire command stack would have to be sent to someone. However, this data isn't stored on the server, but each client has their own (identical copy).

Would it be bad for when someone joined to have the server ask one of the clients (which? round-robin?) to send his command stack to the server and have the server forward it to the client? My concerns are the delay and teh amount of data being sent in one go (congestion).

What do you all think? Are there any other options?

\$\endgroup\$

1 Answer 1

Reset to default
1
\$\begingroup\$

Unfortunately, there is a flaw in what you're suggesting.

If ClientA starts the session, does stuff, then gets disconnected for any reason, then ClientB joins the session, who's going to send the stack to ClientB?

You should store the stack on the server and send it to the clients as they join. This will have also the advantage of preventing around with messing with the stack.

And you'll probably eventually filter out commands on the server for any reason. So you should keep you server as 'the authority'.

\$\endgroup\$
4
  • \$\begingroup\$ Your situation would never happen because if there is ever only one (or zero) person(s) in the room then the room is reset. Are there any other examples you can think of? \$\endgroup\$
    – Lawrence Douglas
    Commented Sep 25, 2015 at 14:41
  • \$\begingroup\$ Hmm, I would suggest you review this feature, as it could be annoying if someone gets disconnected because of internet problems or whatnot. Other than that, I don't see any issues with what you're suggesting. My suggestion would be try and see. To 'work around' delays, there is nothing preventing you from showing a 'please wait' message, and for the congestion, you could split your large stack into smaller chunks. But start by seeing if there are issues with this first. \$\endgroup\$
    – Vaillancourt ♦
    Commented Sep 25, 2015 at 14:53
  • 4
    \$\begingroup\$ Rule Number 1: Never trust data from any client. What if a user uses an altered client? Every one joining the room is in danger now if you redirect the user stack to the other users. If you have to check it first, than you can also store it at the server in the first place. Better store stack on the server. If one user alters the stack (for example by pushing a new rectangle to the server) every client gets a notification that the stack has altered and the client has to refresh the data. Send Heartbeats from the server to the active clients, if no client answers after x tries, clear the room. \$\endgroup\$
    – Ello
    Commented Sep 25, 2015 at 15:09
  • \$\begingroup\$ @LawrenceDouglas There is an obvious security flaw in just broadcasting data coming from a client. If one client finds a way to make an infinite stack with random commands, the server AND the new client will be in DoS. Thanks to Ello for pointing that out. \$\endgroup\$
    – Vaillancourt ♦
    Commented Sep 25, 2015 at 15:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .