Small proposal for lobby protocol extension

[Licho]

I would like more generic way to look at this - I would like ability to attach custom data to player and battle. Ideally in the form key=value dictionary.

This could be used by lobbies the way they want without need to change protocol and server.

[AF]

+1000 to lichos suggestion

[echoone]

I would like more generic way to look at this - I would like ability to attach custom data to player and battle. Ideally in the form key=value dictionary.

This could be used by lobbies the way they want without need to change protocol and server.

Doesn't that then open the door for unofficial mandatory compliance? Else, creating a world of haves and have-nots depending on which lobby client is in use.

How many lobbies actually exist and are in use at this point? TAS and SL. Any others?

[AF]

As a lobby developer, this makes sense. I remember when they added mod and map options, which streamlined a lot of code, this would be of enormous help.

Wether its all hard defined or not, there would still be haves and not haves.

[Pxtl]

In this case, have and have-not lobbies work together nicely, if the key-value pairs are primarily being used for things like rank limits.

The pair just informs the lobby that a rank limit exists. The client will still get the hard "you've been kicked because of rank limit" error when they attempt to connect to the room, even if the client doens't support the rank limit tag. Behavior is annoying, but it's not like a complete failure of the client to support the room's logic.

[echoone]

As a lobby developer, this makes sense. I remember when they added mod and map options, which streamlined a lot of code, this would be of enormous help.

Wether its all hard defined or not, there would still be haves and not haves.

I don't think that really addressed the concern. One is documented. One is not. One is ripe for abuse; including potential DOS'ing. The other is not; or less so.

If important features are so impossible to get added, it suggests a broken process. I'm not sure adding the wild west is a cure for a broken process. Why not fix the process and simply advocate your feature request?

[AF]

That's just alarmist. We already have features which could be exploited in that way, and there are already security measures in place to hold back the potential of DOS attacks.

Its a good idea, that has the support of all the lobby developers so far, none of the people who work directly with the protocol have raised an issue with it, it'd work very similarly to protocol commands we already have, and it'd make our jobs a lot easier.

[Licho]

Main benefit is that we can extend what lobbies can provide without need to modify and redeploy server.

All thats needed is for lobby to be changed (or if its feature for multiple lobbies, for lobby devs to post key and their usage somewhere).

[echoone]

That's just alarmist. We already have features which could be exploited in that way, and there are already security measures in place to hold back the potential of DOS attacks.

Its a good idea, that has the support of all the lobby developers so far, none of the people who work directly with the protocol have raised an issue with it, it'd work very similarly to protocol commands we already have, and it'd make our jobs a lot easier.

It may be many things, including a neat idea for extensibility, but "alarmist" it absolutely is not. Interestingly enough, none of the questions were answered. If statement of fact makes you believe the statement is "alarmist", then it suggests its not a good idea.

Your answer is what is called hand waving and dodging.

[echoone]

Main benefit is that we can extend what lobbies can provide without need to modify and redeploy server.

Has that traditionally been a problem?

[hoijui]

that is probably the greatest problem in spring community.
soo... yes!
in general, most people talking in here know what they say, and are around since quite some time .. you may see that on their join dates, and by what you may already know what they are doing (lobby deving, eg).
or in other words, try to trust a bit more in others, and a bit less in yourself (in here)!

btw, the properties thing is on the TODO since some time already.
this has nothing to do with this thread though, as this is about finding a fast, non-problematic short- till mid-time workaround for the problem.
so.. please talk about that again!

[koshi]

in general, most people talking in here know what they say, and are around since quite some time .. you may see that on their join dates ....
or in other words, try to trust a bit more in others, and a bit less in yourself (in here)!

No. Just no. You do know the amount of bullshit, longtimer or not, that is sprouted around these forums is enormous.

[hoijui]

i meant this thread mainly. and with my description i meant to include BD, AF and Licho mainly.
sorry for the being unclear.
though in general.. i don't think many (any?) lobby dev talks big bullshit about lobby clients and lobby servers in general. same for engine devs and engine ... and so on, if they were around for some time.
it surely is better to not think you know it better, while being new here and not being a lobby-client or -server dev.
as this thread has given an example for that rule.

[aegis]

I'd love to support server-independent protocol for things as long as we established a usable standard (forum for proposing ideas and setting standards so we aren't forced to implement it however the first person did it)

there's also a fairly new compatibility flag thing going on, and I think we could push a lot of functionality using it. part of the plan for uberserver was to make different protocol versions easily accessible through classes/inheritance (each client can have his own separate Protocol instance), and it would be awesome to put this to good use with compatibility flags.

also, we should maybe have a new compatflag for "supports server compatibility" so the server can advertise to the client which features it supports

I don't approve of storing *any* extra data in numbers (like bitfields/bitmasks) for purposes of lobby/protocol, and most or all of the other current lobby/protocol devs will agree with me. it's too much of a pain.

[Licho]

Examples of thins I could support easily with properties:

Elo rating for players
QuickMatching data on players
PlanetWars marker for battle
Elo based limits on battle
Ladder games marked and cup given to ladder leaders
etc etc..

[AF]

What i would suggest is that we have a registry of allowed custom messages/keys the server has, each grouped together into command sets, so that we can then say that the client has no, partial, or full support for that commandset if queried by the server, and the host can submit a list of command groups it supports, and the server can send a list of the lowest common denominators on join/update.

Then we can pretty much nuke about half of the 50 or so commands and their options from the protocol.

[echoone]

I'd love to support server-independent protocol for things as long as we established a usable standard (forum for proposing ideas and setting standards so we aren't forced to implement it however the first person did it)

And that addresses my concerns. No more wild west and things are actually documented. Everyone gets a chance to drink from the cup. Excellent.

also, we should maybe have a new compatflag for "supports server compatibility" so the server can advertise to the client which features it supports

The combination addresses both current and future compatibility and fighting off ad-hoc, undocumented, defacto, specialized implementations which would otherwise create a world of incompatible haves and have-nots. Excellent.

+1000 aegis