Spring RTS Engine

Licho wrote:I would still like to add federation feature to connect servers together

Not sure how this would be possible if the two servers don't obey the same protocol?
There are also some huge issues like conflicting user names, channels, battlegroups.. and so on. It just doesn't seem likely to happen.

Licho wrote:or merge ZK fork into springrts.com uberserver.

This is never going to happen with changes such as this: https://github.com/ZeroK-RTS/Zero-K-Inf ... 400e9868f0 .

Licho wrote:Well I talked with all of them later real time in #zkdev and nobody asked me to stop ...

I would still like to add federation feature to connect servers together - or merge ZK fork into springrts.com uberserver.

feel free to to contribute to the official server. but imo it doesn't make sense to add encryption to the server and then create a "federation" connection which sends all data unencrypted to the other server. -> connection has to be encrypted. but you removed all encryption stuff, so this very likely won't happen. also you've to maintain two lobby servers, i don't see someone willing to do it.

this is why i suggested the "melbot" approach, but this wouldn't allow to join games on the other server.

It does make sense if the federation does not exchange any senstivie data...
Read my proposal there is no LOGIN info exchanged does not contain password/hash things.. only ID because in federation servers would trust each other.

How servers would be authenticated is another thing and it can use IP and account whitelist or whatever, but *not* for the actual data...

Also the proposal takes into account possible changes in protocol.. only some subset of commands in current format would be sent. Just the things critical for starting game.

Licho wrote:It does make sense if the federation does not exchange any senstivie data...
Read my proposal there is no LOGIN info exchanged does not contain password/hash things.. only ID because in federation servers would trust each other.

How servers would be authenticated is another thing and it can use IP and account whitelist or whatever, but *not* for the actual data...

Also the proposal takes into account possible changes in protocol.. only some subset of commands in current format would be sent. Just the things critical for starting game.

define sensitive data: are channel/battle passwords sensitive? (imo yes, they are)

imo the work will be like close to a lobby-server rewrite. there are A LOT of commands which needs to be forwarded so it works well: don't forget stuff like nat-hole-punching, what about smurfs/ip/user-ban lists, user id conflicts, etcetc. you have to make an additional protocol to do that which is a lot of extra work for both implementations. it would be easier to start a lobby server from scratch without having to worry about compatibilities.

basicly your suggestion is to allow proxy connections and then sth. like melbot could be used. only requirement would be: to either use the CONNECTUSER stuff or allow one client to host multiple battles. i don't see how your suggestion can be done without a lot of work. would it be worth the benefit?

why not change the clients to allow two connections? or why not make the current implementation more efficient, so it can handle 7k clients? (maybe it already can, idk)

this is a bit off-topic in this thread.

Battle and channel passwords wont be encrypted even in Kloot secured uberserver so this point is invalid. (Also there is no point supporting locked battles/channels, this is about basic functions)

Banning, ID conflicts were covered in the proposal.. but ok, it is some work ..

Also melbot will solve chat but not battles.. I can of course hack battles but would you be happy about "ghost teams all" battle with 20 ghost accounts in it?