1
\$\begingroup\$

I'm developing a game that has a lot of rooms and most rooms will have between 2 and 15 users. On the UI there is a list of all the players currently in the room. I'm wondering, when someone joins a room, should the server send the entire list of players (admittedly not much) to everyone, or just the delta?

Option 1) Send the entire list to the new person joining because he needs all of them and send the one user to the rest of the players because they already know who else is in the room. Possible synchronization issues and harder to code.

Option 2) When someone enters or leaves a room, resend the entire list of players to everyone. No synchronization issues, much easier to code and test, but increased packet sizes.

Which option would you choose or is there a third one? For reference I'm using node.js and socket.io.

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Go for the easiest implementation that reliably meets the scale and performance needs of your application. So, since you've said nothing about the needs of your application in this regard, we can't help you decide that. \$\endgroup\$
    – jfriend00
    Commented Sep 11, 2015 at 17:00
  • \$\begingroup\$ How much data needs to be sent per player? how many rooms? How often do players switch rooms? You will probably do well with the simplest solution, which is to send the whole state of the room. \$\endgroup\$
    – VaTTeRGeR
    Commented Sep 11, 2015 at 17:02
  • \$\begingroup\$ I guess what I'm mostly asking is if I'm missing something that might cause a synchronization issue or what the most common approach is in this scenario. \$\endgroup\$
    – Charles Aube
    Commented Sep 11, 2015 at 17:03
  • \$\begingroup\$ Players don't switch rooms that often. The data that would need to be sent is just the names of all the players and their current scores. \$\endgroup\$
    – Charles Aube
    Commented Sep 11, 2015 at 17:04
  • 2
    \$\begingroup\$ Generally, you want to keep the traffic as low as possible, as far as I know the best practice is to send delta, but have a sync mechanic(resend) run from time to time. But for your scale, anything but the simpliest solution would be overkill \$\endgroup\$
    – wondra
    Commented Sep 11, 2015 at 17:11

2 Answers 2

Reset to default
1
\$\begingroup\$

Send the whole list. It will probably fit in the minimum packet size of your network.

For example, Ethernet packet size is usually 1500 bytes, and Wifi is usually 2312 bytes. Your upper bound list of 15 user ids (names?) should fit in one, or maybe two what with various overhead & metadata you might have.

And, just generally, get it working, and let evidence guide further optimizations...

\$\endgroup\$
0
\$\begingroup\$

A third option of sorts: Sufficiently large (or privacy minded) IRC channels may not send a user list, and may not even send join/part notifications. The IRC client can build up a user list by adding anyone missing when they chat, since e.g. their nick is encoded into the chat message anyways.

The IRC server may be configured to send join/part messages, and may be configured to send a user list on joining, but it's no big deal if it doesn't. You just end up with an empty user list that's only populated by people actually chatting. The client may request a user list and overwrite it's local list if it receives a response - but again, no big deal if there's no response.

Different IRC clients end up with only partial user lists in these cases as a result, but that's not actually a big deal. And when the server does send the necessary information, the only sync issues I've run into, when implementing IRC clients and bots, had to do with not properly handling case insensitive identifiers, or mishandling "myself" - nothing to do with the specific protocol style used.

I imagine the server side is similarly straightforward. Doubly so in nodejs, where you don't have to worry about multithreading.

\$\endgroup\$

You must log in to answer this question.

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