Network code bug
Moderator: OpenTTD Developers
Network code bug
Hi,
if found the network code bug that results in random disconnects i think.
The Problem is, that the code thinks, that the data stream is continuous, but it isn't. The network connection is made via udp, which has the feature to not resend lost packages.
So, there are two possible ways to fix:
Use TCP instead of UDP. But this is not a good solution. The most games use udp, because the resend of the package would be outdated anyway.
Instead the code need more error checks. First of all, all packages have to be signed by a prefix magic and a suffix magic plus checksum.
A package starts with a magic, this could be a char with suffix checksum check or a string like "oTtdS". Without suffix checksum, a single char isn't enough. But i suggest:
byte magic
byte packet_len
byte type
byte packet[packet_len]
byte magic
byte chksum[4]
checksum algorithm could be something like crc32, not to strong because we don't need cryptographic security
the parse method looks for the next magic, then checksums from packet_len to packet[packet_len]. Looks for the magic and compares the checksums, if the are vaild, continue.
If the checksums doesn't match, search for the next magic and discard everything before the new magic.
Using UDP does also require to resend updates, the server can't assume the client state.
if found the network code bug that results in random disconnects i think.
The Problem is, that the code thinks, that the data stream is continuous, but it isn't. The network connection is made via udp, which has the feature to not resend lost packages.
So, there are two possible ways to fix:
Use TCP instead of UDP. But this is not a good solution. The most games use udp, because the resend of the package would be outdated anyway.
Instead the code need more error checks. First of all, all packages have to be signed by a prefix magic and a suffix magic plus checksum.
A package starts with a magic, this could be a char with suffix checksum check or a string like "oTtdS". Without suffix checksum, a single char isn't enough. But i suggest:
byte magic
byte packet_len
byte type
byte packet[packet_len]
byte magic
byte chksum[4]
checksum algorithm could be something like crc32, not to strong because we don't need cryptographic security
the parse method looks for the next magic, then checksums from packet_len to packet[packet_len]. Looks for the magic and compares the checksums, if the are vaild, continue.
If the checksums doesn't match, search for the next magic and discard everything before the new magic.
Using UDP does also require to resend updates, the server can't assume the client state.
Re: Network code bug
UDP is only used to find the server on a network. The game runs through TCP. And TCP is perfect for this, because no data is lost and a little lag does not hurt, because OpenTTD is not a close combat type of game. I haven't looked into the desynch problem yet, but if you have a fix, it's of course greatly appreciated.poelzi wrote:if found the network code bug that results in random disconnects i think.
The Problem is, that the code thinks, that the data stream is continuous, but it isn't. The network connection is made via udp, which has the feature to not resend lost packages.
"There's a readme that comes with the source. I suggest you read it."
- Korenn
- Korenn
-
- Route Supervisor
- Posts: 389
- Joined: 04 Feb 2004 23:24
- Contact:
Desynching seems to happen very often as it switches from one month to the other. I first thought the monthly autosave (almost required in net play) was causing the problem... so we both turned it off but I was still getting disconnected... so my next guess is the difference in computing power (dual P3 733MHz vs. P4 2.5GHz) is the likely cause... would there be some way for the client that is "ahead" of everyone to wait a few frames... just to resynch the game?
Siggy not gonna work unless someone allows javascripting...
I already suggested that developers could make the lan game like in starcraft were the slowest performing pc dictates the speed that others folow so there would not be any desynch.
And you can get an example of that multiplayer in c coding here: http://www.relic.com/rdn/index.php register and download the homeworld source it should contain multiplayer.c or something like that the code is in c and the game's multiplay runs in a way that i said before
And you can get an example of that multiplayer in c coding here: http://www.relic.com/rdn/index.php register and download the homeworld source it should contain multiplayer.c or something like that the code is in c and the game's multiplay runs in a way that i said before
- lucaspiller
- Tycoon
- Posts: 1228
- Joined: 18 Apr 2004 20:27
I also think desyncs might have something to do with differences in computing power. For example if you have the server on a fast PC (e.g. 2ghz processor) the game will run at a speed that is good for that computer, but if a client is an old PC (e.g. 200mhz processor) with full detail options on it may not be able to keep up with the speed at which the server is running.
The way in which (I think) the game is kept in sync is by syncing the random seed number and the server sending out to the clients what frame it is on. This only happens every few frames though rather than every frame. I don't really know how the frame system affects gameplay but if the client is a few frames behind the server I don't think it would hurt to skip a few, or if it is ahead to wait a bit.
I will do some more experimenting to see if I can find anything out because this is one of the most annoying and on-going bugs in the game that still hasn't been solved....
The way in which (I think) the game is kept in sync is by syncing the random seed number and the server sending out to the clients what frame it is on. This only happens every few frames though rather than every frame. I don't really know how the frame system affects gameplay but if the client is a few frames behind the server I don't think it would hurt to skip a few, or if it is ahead to wait a bit.
I will do some more experimenting to see if I can find anything out because this is one of the most annoying and on-going bugs in the game that still hasn't been solved....
No longer active here, but you can still reach me via email: luca[at]stackednotion[dot]com
-
- Route Supervisor
- Posts: 389
- Joined: 04 Feb 2004 23:24
- Contact:
Hrm... did some thinking and I'm not sure if it's entirely cpu power related.... been running on fast mode occasionally with a friend of mine... even with 3 people... no desynch (large rail networks for each player)... yet it still randomly lets people desynch on normal speed.
Siggy not gonna work unless someone allows javascripting...
the speed of the different computers in a network game is totally insignificant. The server synchronises the game state before allowing things to continue so it will automatically go at the speed of the slowest computer/connection combination.
I played in an 8 player game on the internet for hours where most players were in brittain and using a modem dial-up. there was maybe 1 desync, but that player reconnected and all was fine again.
I played in an 8 player game on the internet for hours where most players were in brittain and using a modem dial-up. there was maybe 1 desync, but that player reconnected and all was fine again.
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
-
- Route Supervisor
- Posts: 389
- Joined: 04 Feb 2004 23:24
- Contact:
very sure. although that was the official release, not the nightly build, and the nightly build is not garantueed bug free.
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
-
- Route Supervisor
- Posts: 389
- Joined: 04 Feb 2004 23:24
- Contact:
Wow, 0.4.0 Can you send it to us? Then we can just do an immediate update from 0.3.4 to 0.4.0 and not go through this process is lots of work to do
Anyways, 0.3.4. network is really buggy unfortunately. You can try the SVN version; but pretty soon a new network is out that will be a lot and lot better!
Anyways, 0.3.4. network is really buggy unfortunately. You can try the SVN version; but pretty soon a new network is out that will be a lot and lot better!
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
Who is online
Users browsing this forum: Bing [Bot] and 1 guest