## -= TECHNICAL ABBENDUM =-

### Networking - Timeouts and the tcpnetdrv

Many server admins forget to properly configure their tcpnetdriver.

There are 2 very important settings which are totally set wrong by default, I will explain what these settings do and why you should enable the "FastTimeOut" option in the networking options from UTeamFix technical options.

    ipdrv.tcpnetdriver InitialConnectTimeout

This setting is 500 by default (500 seconds = 8 minutes, 20 seconds). It is the time that Unreal will keep up with clients which connect (prelogin) and download files which do no longer have contact with the server. Since the default value is by far too high, failed connections (or rejected players at prelogin) will add to the "dead connections" list and also cause the client count to go up and show a totally wrong number.

The longer the list, the more difficult it is to track IPs correctly (and the longer it takes). Although the inbound IP tracking is highly efficient, there is no need to cause unnecessary CPU cycles to be used up searching through a ton of outdated data.

The "FastTimeOut" networking option will set this time to 30 seconds! You will notice a much(!!) more accurate client count on your server console and all dead connections being removed very quickly.

    ipdrv.tcpnetdriver ConnectionTimeout

I first believed the other setting was responsible for the fact that clients had problems connecting at times, either because the server lags OR the clients have a slow harddisk.

But it is actually much easier once you understand it. This setting comes into play when the client has already connected. That means when the client has passed the prelogin (password, ban checks...) and downloaded any files it was missing.

As you know, Unreal creates (spawns) the player before the player is able to control it. The reason is this, that after the download the login is executed immediately at the server, but the client at that moment is only starting to load all the packages (something the server does not need to do, as it has all packages in memory at this point of time), because of that, the client code execution is BEHIND the server, and the connection timer starts ticking because the server sees the client as being "connected".

Now what's the problem?

Quite simple, the default value for ConnectionTimeout is 5 seconds, so that means a client has 5 seconds time to load all needed packages and take over the player pawn spawned on the server! OUCH!!!

On fast machines, tihs is normally not a problem. Still graphic cards "prefetching/precaching", slow harddisks or huge custom files can still enlarge the time greatly the client needs to fetch up with the server. And if that happens, the server thinks the client has timed out, although in reality it was just not fast enough loading stuff.

And then the client cannot enter the game correctly. Often you can see messages (without names) on your HUD, but you cannot move, shoot or see any items. This is a very common problem especially on servers running large mods like U4E and people downloading the mod directly from the server (damn lazy punks can't install stuff beforehand...).

But the solve is easy... just give them some more time. 30 seconds are seen to be enough nowadays for all clients to get into the game. ConnectionTimeout is set to 5 seconds as a side effect.

### ADDED

It seems setting the servertravel pause above 10 seconds runs the risk of clients losing connection at map change, regardless of timeout settings :(

!!SOLVE!! User Network.AddTimeMapChange and have a very small ServerTravelPause :)