Hi there!
First of all: I'm in the lucky position of having very few disconnects, therefore I haven't read through all articles. As I'm not asking for concrete assistance, I haven't posted in that sub-forum. Furthermore, I don't have a concrete improvement suggestion (although I hope, that we can develop one here), I didn't post there.
It's just so annoying seeing others disconnect, if you're in a good race with them (especially in longer and / or league) races.
I think, we should divide disconnection-problems into three categories:
1) Client-side problems
2) Some kind of routing problems
3) Server-side problems
1) Client-side problems
There exist a lot of them. Starting with network-driver-problems, going on with background-tasks and ending with wlan-interferences. I think, nearly everything that could happen here, has been already said and can be found with the search-function.
If anyone likes to collect these problems and links to solutions, feel free to contact me and I will edit this post accordingly.
2) Some kind of routing problems
In my personal opinion, this part is a bit overseen. Everyone knows this situation when you're browsing the web, clicking on a link and waiting, waiting, waiting. Then you decide to hit the back-button of your browser and reclick that link and it loads immediatly.
I know only the very basics of tcp-connections, but it seems, that even they fail to reach their destination and I can only imagine that one node in your initial route failed. After re-clicking your link, another route might be chosen and everythings fine again.
3) Server-side problems
If the provider decides to do some weird updates or the servers capacity is maxed out, we see people disconnecting. It's pretty much the same as on client-side, although we can generally assume, that the server's connection is more stable than the client's one.
Very vague improvement idea:
This is the point where I'd like to start a nice discussion :-)
So we know, there are problems in part 2 and 3. What do we do in the computer-world, if we know, something could fail? We create backups...
Maybe, we could somehow connect 2 servers together, so that a client has two options to send packets to or receive from. We see this solution a lot in everyday usage: DNS-Servers, DB-Servers and so on...
Of course, it'd be way to expensive, if we always need two servers (especially public servers), but for "important" races, it'd be affordable to have a second server.
Where my knowledge and ideas end is a concrete solution of how such a backup-solution could work.
But in general, we can say that
a) the two servers must know each other and be somehow linked together
b) the client needs to know, there exists a backup-server and has to decide where to send position packets.
ATM, I can only think of having the client send its packet always to both servers what would be very stupid. I think, the poor 56K-Users definitly won't have a chance to race us then...
So there needs to be some kind of client-side lag detection, like
a) "Hey server1, I need some updates, where the other cars are!"
b) "waiting..."
c) "Hmm, no packets received. Server2, can you tell me, where they are?"
d) server2 answers
This type of fallback would pretty much eliminate all "mass-disconnect" problems, as both type 2 (different route to second server) and type 3 would be a bit safer...
So, just some vague ideas here. Maybe someone can leave some comments on those :-)
Regards
Red Runner
First of all: I'm in the lucky position of having very few disconnects, therefore I haven't read through all articles. As I'm not asking for concrete assistance, I haven't posted in that sub-forum. Furthermore, I don't have a concrete improvement suggestion (although I hope, that we can develop one here), I didn't post there.
It's just so annoying seeing others disconnect, if you're in a good race with them (especially in longer and / or league) races.
I think, we should divide disconnection-problems into three categories:
1) Client-side problems
2) Some kind of routing problems
3) Server-side problems
1) Client-side problems
There exist a lot of them. Starting with network-driver-problems, going on with background-tasks and ending with wlan-interferences. I think, nearly everything that could happen here, has been already said and can be found with the search-function.
If anyone likes to collect these problems and links to solutions, feel free to contact me and I will edit this post accordingly.
2) Some kind of routing problems
In my personal opinion, this part is a bit overseen. Everyone knows this situation when you're browsing the web, clicking on a link and waiting, waiting, waiting. Then you decide to hit the back-button of your browser and reclick that link and it loads immediatly.
I know only the very basics of tcp-connections, but it seems, that even they fail to reach their destination and I can only imagine that one node in your initial route failed. After re-clicking your link, another route might be chosen and everythings fine again.
3) Server-side problems
If the provider decides to do some weird updates or the servers capacity is maxed out, we see people disconnecting. It's pretty much the same as on client-side, although we can generally assume, that the server's connection is more stable than the client's one.
Very vague improvement idea:
This is the point where I'd like to start a nice discussion :-)
So we know, there are problems in part 2 and 3. What do we do in the computer-world, if we know, something could fail? We create backups...
Maybe, we could somehow connect 2 servers together, so that a client has two options to send packets to or receive from. We see this solution a lot in everyday usage: DNS-Servers, DB-Servers and so on...
Of course, it'd be way to expensive, if we always need two servers (especially public servers), but for "important" races, it'd be affordable to have a second server.
Where my knowledge and ideas end is a concrete solution of how such a backup-solution could work.
But in general, we can say that
a) the two servers must know each other and be somehow linked together
b) the client needs to know, there exists a backup-server and has to decide where to send position packets.
ATM, I can only think of having the client send its packet always to both servers what would be very stupid. I think, the poor 56K-Users definitly won't have a chance to race us then...
So there needs to be some kind of client-side lag detection, like
a) "Hey server1, I need some updates, where the other cars are!"
b) "waiting..."
c) "Hmm, no packets received. Server2, can you tell me, where they are?"
d) server2 answers
This type of fallback would pretty much eliminate all "mass-disconnect" problems, as both type 2 (different route to second server) and type 3 would be a bit safer...
So, just some vague ideas here. Maybe someone can leave some comments on those :-)
Regards
Red Runner