Hi everyone,

1. Have one player host the game, i.e. their phone will act as the host server. The shared resource will sit on their phone.
2. Every time a player potentially adds or removes a word/character, they acquire a Java lock on the shared words/characters.
3. Locks will "wait" for other locks to be removed first.
4. Each call to acquire a lock will have to first check if the word they want to remove or add has already been removed or added by the preceding lock.

Isn't that in essence a locking mechanism? The host phone will need to be aware of who is accessing resources, and block the other phone.

Thank you for your very helpul suggestions and clarifications!

I'll need to use locks on the flags since the words/letters will be accessed and removed at random, right?

Karsten_, thanks for the link and share! For this project I'm working with Java, but I do work with C++ sometimes.

No worries, I'll take a look when you upload it and let you know if I come up with anything!

Thanks for helping me rethink this, at first I was definitely thinking of having a separate thread handle the second player's requests.

In the pseudocode it looks like local requests are serially processed before remote requests.
To have requests processed in the order they are spontaneously generated, would one sort the requests by a time stamp? (after serially retrieving the local and remote requests as above)

Going off of the pseudocode, my thought is to set up a loop to repeatedly pull local and remote requests into the requests queue, sort those by time stamp, then process each request serially in the queue.

E.g.

main {
  while(1){
    requests = read_local_commands()
    requests += deque_remote_player_requests()
  
    sort_by_timestamp(requests);

    for each request in requests {
      ...
     }
    send_letter_state_to_remote_player()
    draw_letter_state_for_local_player()
  }
}

Really glad to get some alternate architecture design ideas. This "funnel"/"bottleneck" architecture hadn't crossed my mind.

To have requests processed in the order they are spontaneously generated, would one sort the requests by a time stamp?

Unfortunately, in a distributed world there is more than one clock, and clocks do not run synchronously.

In your room, find 2 clocks, and compare their times. They will not tell you the same time, often not even within a minute.

At sub-second level which is what we're talking here, don't even bother trying.

That means, in a distributed world, you don't know the precise time. Having more than one independent clock breaks that.

From an attack point of view, I could exploit your sorting by setting the time of my device back by say, an hour. That means I'd always be the first one in the queue.

Not that it would change anything in a 2 player game. Think about it. Processing 1 request takes how long? 1msec? How many requests can a player send each second? 2 (would be a very fast player)? So for a 2 player game, you have max 4 requests in a second, each taking 0.001 second to process, which leaves 0.996 second "empty". The chance you get 2 requests at the same time is neglible.

That means your sort isn't doing anything, as you practically never have a queue. I would suggest to just process requests as they come.

In general, when writing a program, first aim for the simplest possible solution that looks like it will work.

If it does work after coding everything, you're done quickly. If it does not, think more, and fix the problem.

The big advantage here is that you don't waste time on solving problems that don't exist in the final application. Also, after you wrote the program, you have a much better view of all the pieces that exist, and how they relate. That puts you in a much better position to decide how to fix a problem. Maybe you can turn a knob at some other part of the program (like limiting the number of characters that a player can request or display an 0.8 second animation when you get a new letter), and the problem disappears like snow.

For fun, I computed what would happen with 100 players. This is queueing theory with a Poisson arrival pattern, and a single processing server, ie https://en.wikipedia.org/wiki/M/M/1_queue

That gives

? = 200 (100 players each doing 2 requests a second).

? = 1000 (1000 requests per second can be processed).

? = ?/? = 200/1000 = 0.2

avg = ?/(1 ? ?) = 0.2/0.8 = 0.25

var = ?/(1 ? ?)2 = 0.2/(0.8*0.8) = 0.32

The average queue length is 0.25 (slightly more than the 0.2 lower limit you would get if requests never arrive at the same time), The variance gives an impression of how much fluctuation you get on that average. Since a waiting customer happens only for queue lengths > 1 (1 request waiting, and one being processed), even with 100 players you hardly ever get a collision.