Lobby server evolutions

[bibim]

Are we still waiting for a new lobby server ?
I did this tiny TASServer patch to add unique account IDs. It has been tested and it's totally backward compatible with lobby clients which don't handle it.
It was very fast to do so even if it's not used I won't have lost much time. At least I will have tried...
(LOGIN and ADDUSER commands updated in ProtocolDescription.xml)

[Licho]

I would like ability to change max player count and mod without rehosting.

[aegis]

that wouldn't be backwards-compatible, licho...

[YokoZar]

that wouldn't be backwards-compatible, licho...

So let's do it when we're rolling out a new spring version and everyone needs to update things anyway. It's an important feature

[hoijui]

TASServer moved to GIT

New repository:
http://github.com/spring/TASServer

commit rights: spring devs + BrainDamage

edit: thanks to BrainDamage for importing the full history from SVN

[bibim]

Thanks to Lurker for applying the account ID patch on the server.

Well, if TASServer patches are finally accepted, I guess I will write the patch for the first item of my original post (still totally backward compatible with older clients of course...):

- let the battle founder decide if someone can join his battle or not, instead of having to auto-kick

so we can get rid of these auto-kick floods...

[hoijui]

Did some massive rearangement, and added Maven 2 Project files for TASServer and ChanServ.
Maven is a build management thing. It is ... i would say higer level thing then Ant. It is standard based, so you do not have to define your sources dir anywhere if you use the standard location, for example.
The whole Maven config is a single file, pom.xml, which is quite small even. Dependencies are auto downloaded.

Usage

Make sure you have Maven installed, then choose one of the following:

Console
Check if Maven is available:

Code: Select all

mvn --version

cd to the root of the TASServer repository, then:

Code: Select all

mvn package

The first time you do this, it will take some time, as Maven will download all the dependencies it needs for compiling. packaging, and the dependencies of TASServer. Then it will compile and pack TASServer into a jar file under the target/ subdir.
You can now run it with:

Code: Select all

java -jar target/tasserver<version>.jar

or double click on the jar and if the OS asks how to open it, choose java.

Netbeans
Make sure you have the Maven plugin installed, then you can simply open the TASServer repository root as a project. That's it!

Eclipse
i did not try it myself, but Eclipse has Maven support too, so it should be as easy as it is with Netbeans.

[bibim]

Ok so I did this second patch (even smaller than the first one) for the version of TASServer which is currently running.
This allows hosts to decide whether a player can join the battle or not, instead of having to auto-kick him each time he joins the battle.
It has been tested and it's totally backward compatible with lobby clients which don't handle it.
(LOGIN command updated for new compatibility flag, and JOINBATTLEREQUEST/JOINBATTLEACCEPT/JOINBATTLEDENY commands added in ProtocolDescription.xml)

[hoijui]

Performance enhancement hints:

• Perf. loss possibly kicks in when garbage collecting (possibly because of too many temporary objects). This is only a wild guess.
• move Accounts from a flat file storage to a database (MySQL preferably)

As it is now, Accounts data is all read from the disk into memory, and kept there, even though most of this data is never used. Some related statistics:

Code: Select all

Active accounts in the last 1 day:      1101
Active accounts in the last 2 days:     1505
Active accounts in the last 3 days:     1792
Active accounts in the last 4 days:     2037
Active accounts in the last 5 days:     2251
Active accounts in the last 6 days:     2512
Active accounts in the last 1 week:     2795
Active accounts in the last 1 month:    6911
Active accounts in the last 2 months:   11442
Active accounts in the last 3 months:   16018
Active accounts in the last 6 months:   29522
Active accounts in the last year:       63143
Total number of accounts:               124789
Number of unique IP addresses:          99432

thanks to Tobi and bibm for the tips

@bibim
could you please make this patch available in a git branch?
does not have to be on current master head.

[aegis]

if migrating to sql, it'd make sense to use the same database format as uberserver, so switching between the two servers is seamless.

[hoijui]

i agree. could you point me to something where i could see this format please?

[tizbac]

I think that the patch about battles is too much crappy
Would be better instead adding a ban list on server side
Sending a command for each player that tries to join and the send back a response and then send it to who is joining will be laggy also

[aegis]

half-second lag to join a battle is negligible...

i agree. could you point me to something where i could see this format please

gimme a bit, I'll write it up.

note: for simplicity, you'd only really need to copy the user table, since you're only implementing accounts.txt

[tizbac]

At least in italy there's a lot of times 500 ms lag to a tcp server, 500 ms to send joinbattle command.


500 ms to receive JOINBATTLEREQUEST, 500 ms to send response , 500 ms to send joinedbattle to client trying to join = 2 sec
I think that a lot of other countries may have also NATed wifi connection which has more than 700 ms lag
At least it should have timeout , no response to joinbattlerequest in 200 ms = allow.
Since we are also modifying database , and uberserver database (if i'm not wrong) has battle bans for each user, it's better just implementing totally backward compatible banlist without the need of flags on connection

[aegis]

just remembered tasserver stores a single "account access" bitfield for ingame time, bot status, moderator status, etc... while uberserver just separates them.

also, would it make sense to use the new integer at the end of the accounts.txt list as the row id instead of adding a new column for it?

[tizbac]

it stores bitfield in ascii format , that is the funny thing
it has disadvantages of both separated fields and bitfields: Human Unreadable(bitfields) , takes more space(separated fields)

[aegis]

Code: Select all

Table: 'users'
	Column: 'id', Integer (primary key)
	Column: 'name', String(40) # lowercase, was used as a quick hack...
	Column: 'casename', String(40) # uppercase
	Column: 'password', String(32) # md5 + base64, applied by the lobby
	Column: 'register_date', Integer # unix timestamp
	Column: 'last_login', Integer # unix timestamp
	Column: 'last_ip', String(15) # no ipv6 support atm, maybe needs to store as an integer or hash? ipv6 can have several different representations of the same ip
	Column: 'last_id', String(128) # pretty much anything allowed under 128 chars
	Column: 'ingame_time', Integer # unix timestamp
	Column: 'access', String(32) # admin, mod, user
	Column: 'bot', Integer # true/false, should probably be tinyint/smallint or boolean
	Column: 'hook_chars', String(4) # tasserver doesn't use this
	Column: 'mapgrades', Text # ehh I don't think these are necessary... imho server-based map grades should be totally deprecated.

[lurker]

The booleans are prefectly readable, only ingame time isn't.

[bibim]

Would be better instead adding a ban list on server side

Personnaly I prefer the ask-to-founder method, for all the reasons explained in the first page of this thread. Sure a server-side ban would be nice too, but that would require much more changes in TASServer...

Sending a command for each player that tries to join and the send back a response and then send it to who is joining will be laggy also

I don't think so. Except if by laggy you mean an extra delay of 100ms in most cases, which is barely noticeable for the join battle procedure in my opinion (especially when the lobby clients take more time to open the battle window itself, load the map, modoptions etc.).

At least in italy there's a lot of times 500 ms lag to a tcp server, 500 ms to send joinbattle command.

500 ms to receive JOINBATTLEREQUEST, 500 ms to send response , 500 ms to send joinedbattle to client trying to join = 2 sec

Can you define what you mean by "500 ms lag to a tcp server" ? From your calculations it seems you are saying that you have TCP delay of 500ms for sending a packet, and another 500ms for receiving a packet, so a ping of 1s ?

It doesnt seem so at all from my measurements. Here is a TCP ping result from a personal french ADSL connection to your autohost in Italy (so your ping to a standard european tcp server such as Spring lobby server should actually be lower):

Code: Select all

--- 79.19.24.210 hping statistic ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 161.3/178.8/224.2 ms

"rtt" means roud trip time so the time for a packet to reach the destination and come back to you. We are far from 1 second...

Anyway, it doesnt matter how slow is the client connection. What matters is the host server connection latency. Indeed, the only extra packets added by the ask-to-founder method are the 2 packets transmitted between the lobby server and the host. The 2 other packets transmitted between the client and the lobby server are already used currently. Actually, the slower the client connection speed is, the less noticeable will be the extra delay added by the ask-to-founder method. And if you're hosting with a ping of 1 second, the 1 second delay added by the ask-to-founder method for joining your battle will be the least of your concerns imo...

Let's take someone hosting with an RTC connection from Australia as example.
His ping to Spring lobby server should be about: 200ms (RTC) + 350ms (Australia <-> Europe) = 550ms, so an extra 550ms for joining his battle. Do you really think this worst case scenario is laggy ?

I think that a lot of other countries may have also NATed wifi connection which has more than 700 ms lag

Once again what do you mean by "700 ms lag" exactly ? The time to just send a packet ? I don't think a lot of players are hosting with a ping of 1.4s...

At least it should have timeout , no response to joinbattlerequest in 200 ms = allow.

So you mean you wouldn't be able to use this feature with your "500 ms lag" to send a command ?

[bibim]

tizbac, anyway if lurker is kind enough to apply the patch on a test instance of tasserver as he did for the previous patch, we will be able to check the actual latency on real server for joining battles. And if it's unacceptable as you think, this patch will obviously not be applied...

@bibim
could you please make this patch available in a git branch?
does not have to be on current master head.

Actually I don't plan to make other patches for TASServer, so I think it's easier to just provide the patch for current master head (rev 7e577c7):