[RESOLVED] need help figuring out the order of events.. or what events to use..

First off, this isn't a "help me fix this bug" question...

Preamble:
I have a game program that currently only works when both players are on the same network (no problems there). The program can function as either a "host" or a "client" depending on who starts it first (alerts sent via TCP determine this).

The Task:
What i'm trying to do now is remove all the TCP sending and receiving and replace it all with SQL queries (the SQL & queries aren't the problem). I need to come up with a way for my program to "know" if it is supposed to be the "Host" or the "Client" based on queries sent to the SQL database.. But I can't seem to nail down how to do this.

as of now the database for the game consists of 1 table with 3 rows (player, accesstime, data), but i can add as many more as are needed.

Can anyone offer some ideas?

setup a client table that lists all the currently logged on clients, either set the clients to send 'I AM HOST' to it or set the first client logged in as host, something like that, i recommend though allowing the client to specify that it is a host to avoid any confusion.... anything else that connects can then see that there is a host available and connect accordingly.

That's the direction i keep leaning toward... But how do you account for a user that's listed, but it's not from an active game rather a crashed one (esp if that user was the old host)?

or more accurately, how do you know if the user listed is from an old session and not current?

I'm not sure that this can be totally solved without ending up with a race condition.

What you've described sounds like a LAN game. Those were generally based around UDP, and you might consider that, as well. Unlike TCP, UDP doesn't have connections, so there is no host and no client. Everybody is both. These were used for LAN games because you can broadcast messages really simply, and the messages are faster than TCP. A game could be firing off messages about the position of items, and updating itself with messages from the others. If a message was missed, it didn't matter because a new message would be along shortly.

Beyond that, you could use UDP to solve the problem that you are talking about. I have a program that does the same kind of thing. One system is the master, while the rest are subordinate, but I don't know which will be the master, and the master can leave at any time. The way I solved it was to send out a UDP ping periodically. The master would include it's ID (just a GUID, in my case, but it could be anything) in the message. Any system that got the message, would see that the ID was not its own ID, so it would know that it was subordinate. That periodic message acted as a suppressor. If the master system was shut off, then the subordinate systems would stop receiving the suppressor message. If a system hadn't gotten a suppressor message in twice the period, then it would start sending suppressor messages of its own, which would then suppress all the other systems.

I set it up so that the suppressor message would go out about once per second, which is fairly slow. Therefore, each system would start a three second timer whenever it got the suppressor message. If a new suppressor message arrived before the timer ticked, then the timer would reset. If no suppressor message was received, then the system would start sending suppressor messages of its own. I could have used a faster timer, and a faster period, if I wanted the master/subordinate relationship to be more responsive, but in my case it didn't matter.

The system was also sending other messages. The suppressor ID was added to EVERY message, so every message acted as a suppressor message, but there would be long times when no messages were going out, so I also had that periodic message just to keep the suppressor signal firing.

I'm trying to avoid the idea of "sending" data to other clients, as the end goal is that the game can be played online.. (not in a "retail" sense, but a "family lives everywhere and we want to play it" sense).. without needing to know everyone's IP's.

random thoughts..

i set the game to always assume it is the host... unless it gets a response (in the way of a message changed on server)
"Session 1" logs in.. sees what appears to be a host, so it uploads a "hello" post..
if the other user is actually there it would see the post (via a query check on a timer loop that was started when the game opened).
if there is a response, then "Session 1" switches to a client role. If not, it wipes the database and re-adds itself as Host. Then it waits for Session 2 to join..

?

If they are on one network, UDP doesn't need IPs. A broadcast message goes out there, and anybody listening gets it. They pretty much have to be on the same network, though, as most firewalls block UDP by default. Can't imagine what a broadcast message would do if it escaped a network. That could be enough spam to feed a nation for a year.

Quote:

---

Originally Posted by Shaggy Hiker

If they are on one network, UDP doesn't need IPs.

---

Right, but that's the point of this particular exercise, they won't be on the same network. Not even in the same Cities.

The DB could have a Godfather table. When an application starts up, it could check the table to see that there is nothing in there. If there isn't, it could write its own name in there. If there IS something, then it would do nothing.

That won't hand anything off, though. You'd also have to have a time stamp along with the name, and every system would have to check the time stamp fairly often, only wiping things if the time stamp is really out of date.

Both parts of that have issues. You have a race condition in the first part, and the second part would mean a fair number of connections, all looking at the same record, so writing could end up being problematic.

You might be able to be a bit more efficient with a stored procedure, which would help solve the race condition. The stored procedure would take the ID of the caller and output the owner ID and the time stamp. What the SP would do would be to compare the ID to the existing ID. If there is no existing ID, write the incoming ID and the current time. If there is an existing ID, and it matches the incoming ID, then update the time stamp. If there is an existing ID and it does not match the incoming ID, then compare the time stamp to the current time. If it's out of range, replace the existing ID with the incoming ID and update the time stamp. Otherwise, do nothing.

In all cases, return the existing ID and the time stamp.

This would mean thrashing the heck out of the DB, unless you can tolerate lengthy delays between checks. The programs would almost certainly be doing that in a background thread, since you are performing a round trip to the DB each time. It also doesn't totally solve the race condition. I'm not sure how re-entrant stored procedures are.

Food for thought.

Will have to try some of this out and see how it goes.

TY SH.

i dont think the DB will have a hard time dealing with just a few requests at a time, unless your planning on going mobile :D

Quote:

---

Originally Posted by CWITT

random thoughts..

i set the game to always assume it is the host... unless it gets a response (in the way of a message changed on server)
"Session 1" logs in.. sees what appears to be a host, so it uploads a "hello" post..
if the other user is actually there it would see the post (via a query check on a timer loop that was started when the game opened).
if there is a response, then "Session 1" switches to a client role. If not, it wipes the database and re-adds itself as Host. Then it waits for Session 2 to join..

?

---

this worked :)