xOR wrote:(..)
Until my new aggressive approach to provoke this error (just wildly try to freeze OpenTTD during the different stages of joining the game) yesterday I didn't have a reproducible scenario. If I report that I am seeing ghosts and can't even tell how it happens you would have rather sent me to a mental clinic instead of trying to fix anything
Yesterday I then added it to the bug tracker and it was already fixed by Rubidium today.
We are mostly very fast with critical denial of service attacks
xOR wrote:(..)
However, I am still not sure whether this was the only section during the connection process that has such a problem. (..)
Connections will no longer 'hang' (TCP has a default timeout of 5+ minutes, so it is quite possible it takes that long before a connection drops. Plenty of time for him to reconnect). We now timeout on every stage in the connection process, and kick you if you take too long
So this issue should be resolved with upcoming stable.
xOR wrote:(..)
I know that and it's a good thing that we got this setting - but what I suggested was giving us a bit more fine granulation of choices for it, which a "pause timeout" would do (e.g. don't pause longer than max_pause_time, where 0 is the default and means "infinite" and any higher number is the timeout in seconds).
Which is what is implemented now
xOR wrote:(..)
It's a bit two-faced if you say at two places how you value our experience but then just tell me that my experience is bulls***.
Your experience was fine
Your conclusion out of those facts was not. That was what I called bulls*** on
Nothing can be wrong with experience
Let me try to explain it a bit more, mostly as I feel it will be valuable for you to diagnose these issues in the future.
Your claim:
xOR wrote:(..)
a player who is this slow will never be able to keep in sync with the server afterwards - as the game unpauses he will start losing ground and be kicked out soon.
(..)
relates 2 events that don't have to be related. For a client to keep up with a server, all he needs to do is have a powerful enough CPU, and grind the map as often as requested. For a client to download a map, he needs bandwidth.
There are typical a few ways a client can be dropped.
- (1) Connection lost, happens when the other side terminates the TCP connection. This happens after 5+ minutes if the line goes dead, or when a client sends a clean TCP termination. The first happens when your DSL modem for example just terminates (power-loss, etc), the second happens when you close down windows / OpenTTD.
- Client timeout. This in fact includes a group of failures:
- (2) Client in unable to process the map, and can no longer keep up (can't keep in sync).
- (3) Client is very late with sending that he is in sync, and times out as such.
From the second post, what I read from you, is that you mostly notice the last group. People with a poor connection which stalls for what-ever reason for a period of time, like the scenario you describe (but I can think up a few others too), can be late with telling they are in sync, and be dropped as such.
The important difference is here. He might be able to keep up just fine, and from the clients point of view, he is doing nothing wrong. From a server point of view, the client is slacking, and will be dropped.
But as you might understand, these events are unrelated, in the way that: a slow download in no way implies that his connection is bad, and that he will be dropped later on. You can't put all people with a slow download in this group. You seem to experience only the last group, and I think that is because the second group goes unnoticed. Even if they take a long time to download, they don't bother you afterwards, so they are not apparent. The last group is the most annoying group. But there is also nothing you can do against this group. In fact, it can be they download the map in seconds, and drop a bit later, every single time. The first group is a problem on its own, which sadly also happens.
So what I try to say, is that the conclusion you made out of the facts, are in fact not related, and they should not be confused as related. You can't predict that a user will be dropped when his download of the map is slow.
I hope this makes it a bit more clear. At least I hope it explains the difference between not being able to keep up, and having a s*** connection. The bigger your map is, the more you notice the first group. The latter is always there.
PS:
xOR wrote:(..)
The premium feature would be a cooldown time - if pause-on-join was already granted to an IP address within the last X seconds, don't pause-on-join again if he starts a new connection attempt.
Because I often see that such players keep on trying, blocking the server for another 10 minutes and so on...
This would typical be something for someone to make for the AdminPort. To me it feels like that would be perfect for there