Posted 10 November 2011 - 11:43 AM
One end sends events to the "server" which updates the game state vector then transmits it.
This works really well, actually I am amazed at how well it works even on low end devices
My problem is coming up with a clean way of closing down the comms at the end of the game.
At the moment I send a QUIT event, then close down the connection.
Of course that is bollocks as there is no guarantee that the QUIT event will reach the target.
So I thought about sending back an ACK to the QUIT, but it's the same problem, no guarantee that the ACK will be received.
Anybody found a way around this that doesn't involve sitting there sending quit events for a couple of seconds?
Posted 10 November 2011 - 03:40 PM
So, your solution starts at the client side only. Essentially, the only thing you can do is a) some sort of countdown-to-close mechanism which is reset upon packet receipt, and/or some active ping/pong between client and server, or c) use a real protocol, like TCP. :sneaky:
Posted 10 November 2011 - 05:22 PM
Posted 10 November 2011 - 06:03 PM
I don't want it to be put in a cache and held until some random time in the future
yuck, tried it, it sucks for realtime games.
I guess the nature of UDP means I have no choice but to add a wait and just sit sending the quit message and waiting for an ack.
Posted 10 November 2011 - 08:59 PM
PS: I'm just bugging you. But, I do find lots of people frequently re-adding about 50-80% of TCP back in, though.
Posted 11 November 2011 - 01:33 PM
I started a "reliable UDP bidirectional comms" system, after about a day of coding I decided I was just writing my own TCP stack
So I junked that and I have been happy with the results thus far, I just hate having to put in delays and resends just in case...
Posted 11 November 2011 - 05:42 PM
The client can quit at any given time. When he does so, he sends a QUIT to the server just in case to let the server know. Then the client immediately shuts down without waiting for a response.
The server expects regular input form the client as to synchronise the game. If a QUIT arrives the server immediately acts upon it without sending an ACK back to the client, since the client is no longer there anyway. If no input from the client arrives at all for a certain amount of time, the server considers the client as "dead" and assumes the client did quit and acts accordingly.
Or do you think this would mess up the connecctions and prevent a gracefull shutdown all together?
edit: I just noticed this is similar to what }:+()___ [Smile] suggested... Never mind then.
Posted 23 November 2011 - 08:47 AM
I've put the game into conformance test now and will let you know the results.
They should be interesting as the game runs on about 20 devices, we should get some interesting data about UDP networking on mobile devices from it that may be useful in the future.
Posted 29 November 2011 - 10:06 AM
The code works well in most cases, some devices do not support the discovery technique we use, they just fail to see other devices running the game, they don't crash though which is good.
The one thing that has caused a problem is that UDP being connectionless, other devices can legally transmit on the same port, so it is possible to get rouge packets.
To get around this I have added a checksum to all data packets and I ignore any packets with a duff checksum.
Speed looks good though, the HTC desire seems to handle the network traffic very well.
Posted 30 November 2011 - 08:49 AM
I think some sort of encryption required to protect from cheat programs.
Posted 30 November 2011 - 09:24 AM
It's not the sort of game that people will bother cheating
Posted 03 December 2011 - 10:23 AM
The problems with UDP can be worked around.
At the moment I am trying to fix a bug that happens about once a day when a packet comes in that is of legal format and size, but is either not from my game, or is massively corrupted.
It's really hard to track down as it only happens about once a day, but it has happened on multiple platforms, so it's not just my machine.
The underlying transport layer is still being written. Eventually it will offer encryption and a hmac-sha1 implementation.
At the moment I am using a packet number and a checksum to make sure the packets are in the correct order and belong to me.
The checksum is my own equation, so a packet with a standard CRC32 on the end will just be treated as a corrupt packet and ignored.
Even with all the issues, UDP is the way to be
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users