Create support for "federation"

[Licho1]

Zero-K is now moving to its own fork of uberserver (to address some pains it has and add features faster).

It would be nice if those servers could be connect over common subset of protocol.
Goal is to have shared set of games and if possible also shared chat channels (dont have to be all and can be treated as special case).

It could work like this:
server B opens connection to server A and relays subset of commands in common format to A. A does the same for B. All data contain (server local) account ID.
Server pushes this to its own data processing as "fake clients" based on account ID supported.

There is no need to relay server-> client communication because each server has its own (identical) logic to do that. All thats needed is client-> server direction. So any commands destined for "remote" users from other server can be skipped because other serve does that.

Example

client 1 sends LOGIN to A
A verifies login and fetches its own local account ID
A relays LOGIN command to B (prepended with account ID)
B trusts A so it creates temp account if there is no direct login/password match - or reuses existing DB user.
A already knows about all players, battles and channels logged to B so it can decide to send ADDUSER for all those people and add battles from them.
When client 1 sends more data to A that is in the common subset, it gets relayed to B prepended with account ID, B then pushes it to its own processing using "fake client" located by account ID.

[Licho1]

Regarding special stuff like say KICK - servers only relay that if it was allowed command for its user.
So if client 1 validly kicks some user on server A, it relays KICK command and B trusts it automatically.

That means that admins from each of the servers have power over all people not just people on their own server.

[abma]

why don't you contribute to the "official" server?

[Licho1]

Well just look what I done to uberserver, i removed like 50% of it including all DB access and instead made it use json services to ZK ... Those sorts of things..
It's still lobby 100% compatible but most admin commands are gone..
I cannot do that with main spring server...

[abma]

i saw what you did, but i don't see a reasonable goal.

fixes/improvements can't be exchanged any more at some point... this is a fork.

for what you write, i suggest to use melbot. as you removed encryption stuff i don't see any acceptable channel to communicate between servers.

[abma]

the user creation/changes/db has be shared as well, else you can write some melbot-like thing, too.

[abma]

i don't see this happen in uberserver without encryption / shared account db.

[abma]

rephrased in #130

[abma]

also, what feature doesn't uberserver have, so you need "add features faster" ?

[Licho1]

Mainly optimization for 7000 people, better banning, no lobbyid duplicities, metadata (what nightwatch does in #extensions channel).
Also I want simple environment where developers can hit F5 and it boots lobbyserver + zk site + springie + zkl all at once to test all stuff together and deploy patches automatically.

[Licho1]

Why do you think encryption is needed?

1. we wont transfer any secrets - LOGIN does not have to send username and password. . just name and account ID since you trust the other side
2. security for "federation" can be reinforced by adding IP list etc or SSL or whatever
3. proposed "secure lobby protocol" is atm not widely adopted.. personally I don't see much value in it. I would rather change zk uberserver so that hash of password is not transmitted during auth, otherwise its nothing secret, there is no need to have always on security, if it were i would use SSL/TLS
4. lobby server wasn't secure for years, why do you insist on it now?

And btw i had to use pre-crypto uberserver because later multiplexer.py does not work on windows (you removed non-linux code from it)

[abma]

1. how to prevent user duplicates?

2. transfer should be encrypted to prevent MITM etc

3. it was added a few weeks ago, don't expect it to be added in a very short time until its stabelized/final

4. (better) security is a goal and was always a goal

btw: pull requests / fixes are welcome to readd windows support

[Licho1]

1. If there is name collision you prepend name with protected "server prefix" .. like zk_Licho or springrts_Abma so that clients can reliably reference remote users by name. It could also be added to all names by default.
   If we need ID we can use "account id" .. there might be 'spaces' ie. reserved bits to avoid collisions as well if its needed, but imo we don't need that because common subset likely wont contain commands that reference players by id.

2. how do you MITM when its tcp and we check for IP ? What harm can be done by such (extremely complex) attack? You cannot steal secrets, you can only disrupt normal lobby operation and for that its simpler to connect directly.
   Does the very low risk and low possible damage justify cost of adding encryption?

[abma]

1. this will break user name length limitations and is imo very ugly

2. useless to discuss that with you, encryption is a must have.

[Licho1]

If something that was never in use is a must have and its useless to
discuss with me, you are the one splitting community.
Dne 10. 1. 2015 3:00 "abma" [email protected] napsal(a):

1. this will break user name length limitations and is imo very ugly

2. useless to discuss that with you, encryption is a must have.

—
Reply to this email directly or view it on GitHub
#129 (comment).