Unofficial Kaillera Server based on original binary

Online Forums Computer/Handheld
1

The front page of the SNEeSe home page exhibits release 0.918 of my Unofficial Kaillera Server; updates will also appear there, until further notice.
http://www.emuunlim.com/sneese/

This server was produced from source code created by decompiling an original Kaillera server binary. It can function as a drop-in replacement for servers running version 0.86 of the official Kaillera server.

Changes over the official server:

Greatly improved internal security (several buffer overflow vulnerabilities patched over, far more error-checking on the protocols to prevent unauthorized commands / spoofing);
Flood protection against chat flooding in game lobbies, as well as game creations and joins;
MotD support that should work with older Kaillera clients;
Two automatic banning systems - one for banning users who have been flooding or attempting buffer overflow exploits from entering the server, and one for preventing users who have been kicked repeatedly from a game from rejoining it;
Additional capabilities given to game lobby creators: setting a limit on the number of users that can join the game, user input remapping, and banning a user;
Game lobbies close only when empty, not when their creator leaves, the least recent player to join the game (otherwise known as player 2) gains all powers of the previous host (including commands to start the game and kick users from it, since the client has no interface for providing for this case);
Improved checking in loading the configuration file;
Generally improved performance;
Reduced difficulty in establishing an initial connection;
Alerts displayed in game lobby when someone joins with a version different from the current host/creator;
Filtering of whitespace characters other than space characters (carriage returns, tabs, etc.) out of chat messages.

A list of the new commands given to game lobby creators/hosts will follow this post.

I’d really like to see some servers switch over, or at least give some reasons why they don’t see a benefit. Problem reports and feature requests are welcome.

2

Summary of Commands Available to Game Lobby Creators/Hosts in Unofficial Kaillera Server (as of 0.917)

Note: most commands announce the effect of their usage to all users in the game.

/limit # - version added: 0.913 - usage: /limit 4
Sets user limit for game lobby. User limit defaults to 8, and can not be changed to a number less than the number of users currently in the game, nor can it be changed to a number greater than the user limit of the server, or 32, whichever is less. User limits are enforced.

/swap #### - version added: 0.915 - usage: /swap 01 usage: /swap 20663
Remaps user inputs on the fly, while game is playing. User inputs are reset on game start. Only the first 8 user inputs can be remapped, or used for remapping. Duplicates are allowed. The numbers supplied are the original player numbers, and are not affected by previous ‘/swap’ commands. Using a ‘0’ for a player’s input means ‘don’t change from previous mapping’. The first example ‘/swap 01’ does not change the input currently used for player 1, but uses player 1’s input for player 2. The second example ‘/swap 20663’ uses player 2’s input for player 1, player 6’s input for 3 and 4, and player 3’s input for 5.

/swapreset - version added: 0.916 - usage: /swapreset
This command resets all input mappings in the game to the state they would be in if no ‘/swap’ commands had ever been issued.

/ban # - version added: 0.916 - usage: /ban 5
This command kicks and bans the specified user number from the game, permanently. Games have no bans when they are first created. The example would kick and ban user 5 (the 5th least recent to join, or 5th in the standard client’s game user list, from the bottom).

/banreset - version added: 0.916 - usage: /banreset
This command clears all bans in the game, whether automatic or requested.

/start - version added: 0.917 - usage: /start
This command starts the game, the same as the start button in the default client. This is necessary so that game hosts who have ‘inherited’ their power from a previous host leaving the game can still start the game, despite their client not otherwise having an interface for it.

/kick # - version added: 0.917 - usage: /kick 5
This command kicks the the specified user number from the game, the same as the kick button in the default client. This is necessary so that game hosts who have ‘inherited’ their power from a previous host leaving the game can still kick users from the game, despite their client not otherwise having an interface for it. The example would kick user 5 (the 5th least recent to join, or 5th in the standard client’s game user list, from the bottom).

3

good shit but people should work on a new client already, not just server.

4

This is sorely needed.

5

Hello TRAC,

there is one significant problem I got with servers running unofficial kaillera server releases (let’s say gametronik running 0.918, am being european) :

when I connect to a server running the enhanced version of kaillera server and with about 25 people or more already connected to it, I obtain the user listing screen with the games currently running but I can’t do anything : no chat messages or even my own join message (the screen remains blank), my nick doesn’t appear on the list, can’t see users when i join games, etc…

It works fine when there is less than 25 people connected.

I believe it’s caused by a personnal configuration (adsl modem or else), but it isn’t doing that with servers running the original kaillera server. One thing I can think of, is that the server sends user list and game list as one packet, and when it’s too big, the information doesn’t arrive correctly and the client is not connected properly (say for example that my modem crops all packets that are bigger than a certain size).

Is it possible to change the way user list and game list are sent ? For example go back to the same method used by the original kaillera server, cause I think i’m not the only one having this problem (let’s say we’re at least 2 :))

Thanks, and good continuation on your initiative to improve kaillera netplay !

(tell me if there is a better site or forum to post threads like that)

6

I’ve received the same problem on servers that do not run UOKS, so I do not think it is a problem in the server software, at least not the server software alone.

That is an interesting theory, though at the moment I can’t do anything to prove or disprove it.

I hate to have to inform you of this, but UOKS should use the exact same method for transmission of said lists as the original server, as it was obtained via decompilation of the original server. As for changing the way they are sent, the client would also need to be changed so that it could know how to receive them. Until the client is decompiled, that is not a practical option.

7

I started a thread on the Kaillera forums about the server full/login problem:

http://kaillera.com/forums/viewtopic.php?p=23086

Let us know if it help you.

8

I have found a minor issue in the UOKS server (flaw from decompile, likely) which could cause it to take slightly longer to assemble the server status ‘message’ for a user that is logging in than it should; however, the form and contents of the packet is the same, and I doubt that the time difference is significant. Still, it will be fixed in the upcoming 0.919 release.

[Note - A ‘message’ is the portion of the Kaillera packets that contain individual data/command blocks. It appears both I and Moosehead use this nomenclature, hopefully this will minimize related confusion.]

The connection process itself should be the same as that of the official server (though with a little more tolerance to lost pings); however, the extra ‘messages’ sent by the server to inform the client of user limits in games (which the client SHOULD be able to derive from the initial server status message, but doesn’t) likely cause problems in login if the packets containing that message are lost.

This can also happen on non-UOKS servers, but perhaps is less likely due to less of an initial packet flood on connect. I do not know if a busy server or one with lots of MotD lines (as both would equate to the same conditions) is more prone to it.

The MotD is sent AFTER all initial ping/pong messages have been negotiated and user login has been accepted, so it can’t interfere with that.

As far as the theory about the server status message being excessively large, this probably is a valid concern. I would estimate that on average, each user adds around 24 bytes to the status packet, and each game around 88. For 20 users and 8 games, this is around 1.1k; 40 users and 16 games, this is 2.3k. One could easily blame this on inefficiencies in the Kaillera protocol, but blame doesn’t solve the problem.

One could reduce the size of the server status message, however basic attempts to do so would worsen the problem of the packet flood.

Overall, for best results while we have no new client software, ALL Kaillera servers, regardless of server software, should limit themselves to an absolute max of 40 users, with 20-32 being more reasonable.

9

UOKS update 0.919 is now available at the SNEeSe homepage http://www.emuunlim.com/sneese/.

I do hope adding the /lagstat command wasn’t a mistake…

10

UOKS update 0.92 is now available at the SNEeSe homepage http://www.emuunlim.com/sneese/.

The connect type display bug in the webserver is fixed, and the connect type limit bug, and message broadcasting (used for many things in the server) has been streamlined.