[Draft] Communication between server controllers

[The_Big_Boo]

Btw the #settings values can be added to the list of the changes that managers/controllers could announce to others.

I was considering script settings as part of GameInfos but having both is maybe better.

Btw, isn't MapListModified enough for maps? Or are there methods which doesn't trigger it?
Anyway, as it's not a request nor an answer, I think it needs a third message type. It also needs a exhaustive list of methods implying these calls, especially for ServerOptions and GameInfos because they can be changed atomically. I'll make a sum up later with the requirements.

[vni]

Interesting would be something like ?addadmin ... so that the servermanager (or whatever) could grant admin permissions right after installation of the servertool.

But (!):
- Echo is available from the "User"-Account, am I right? So this might be a security leak, depending on what is connected
- Maybe this command should be avail only if no other admin is set?

[Slig]

Btw, isn't MapListModified enough for maps? Or are there methods which doesn't trigger it?

right, maps changes should not be needed
(i guess that i have to check why in Fast i don't update the next map panel when MapListModified is triggered :p)

Anyway, as it's not a request nor an answer, I think it needs a third message type. It also needs a exhaustive list of methods implying these calls, especially for ServerOptions and GameInfos because they can be changed atomically. I'll make a sum up later with the requirements.

doing it also for atomic changes (of ServerOptions, GameInfos and #settings) would probably not be bad, btw i think that just knowing that there is a change more globally in them is enough to allow to get them entirely but only when needed (without having to poll them and check changes at regular intervals)

[reaby]

Sorry for the massive wall of text, here is my thoughts after thinking about the problem:

Basic idea is that, each server manager keeps track of its own id (and others too)
Id can be randon generated for every time the server controller starts up, preferably use the pid of the runnable,
is is passed in server controllers name separated with pipe character "|"

Xaseco|12345 --> !0|hello
-----------------------------------------------
Manialive|67890 --> #0|hello
ServerManager|36497--> #0|hello


All server managers are now introduced to each other with own id.
----------------------------------------------

The message protocol is separeted to 2 parts, splitted with pipe character.

First part is composed of action followed by identifier, who the message was ment to and 0 for global.

example:
!0|resync
[action] [identifier] | [command]

possible actions are:
! -> execute
# -> answer
? -> list

the second part is same for execute and answer:

example from the bus:
!12345|kick:reaby,get out!
#36497|kick:success!
[action] [identifier] | [command] : [param], [param2], [param3]...

the second part for the list command:

example:
!12345|list
?45678|kick:kick a player|team:change team|addAdmin:addAdmin to servercontroller
[action] [identifier] | [command] : [description] | [command] : [description]

----------------------------------------------------

Every server controller should react on these global keywords:
hello, register server controller and associate an id with it, send back id
bye, unregister server controller from the current list
resync, resync = fetch again all server parameters

Every server controller should react on these keywords, when they are called via id:
stop, stop service
list, send list of methods available
[all local commands], execute the command and give possible answer

----------------------------------------------------

dunno if this would be good enough

[vni]

why should we implement things like kicking? that can be done via the normal rpc connection of the server manager. it is completely useless, isn't it? Actions for starting stopping rebooting and settin permissions are useful.

[reaby]

it is completely useless, isn't it? Actions for starting stopping rebooting and settin permissions are useful

True, but i used that only for demonstrating the principle...

Very good ideas reaby, I will start in MPAseco with it soon!

Maybe wait little more and refine the ideas in principle and then make it reality - or not, depending on Nadeos decisions.

[vni]

So, here we go.

SMART 0.4.8 now supports the following commands via the "Partyline":

!0|hello - Smart responds with #0|hello:SMART:12345 (12345 can be any number)

!12345|stop - Smart stops
!12345|reboot - Smart reboots
!12345|resync - Smart resyncs (prepared but not functional in this version)
!12345|addadmin:AdminLogin - Smart adds an administrator (prepared but not functional in this version)
!12345|list - Smart lists all available methods.

It reacts on the id (12345) that was initialy sent on the hello method, and on the id 0.

The commands are parsed at the Partyline-Plugin (Source-Code)

[MiniGod]

I think this is all good ideas, but I feel like its kinda amputated using the Echo method, cuz I've always thought that it would be awesome to have inbuilt methods for the controllers.

Methods:

• Identify(string name, [string version], [array methods])
  - Set the name of this controller (does not have to be unique, eg: smart or aseco), optional version, and a list of methods. Returns this controller's ID.
• GetRpcClients()
  - Returns a list of all XML-RPC clients connected (array of ID's? or array of rpc clients struct)
• GetRpcClientInfo(int id)
  - Returns a struct of the rpc client.
• StopRpcClient(int id)
  - Closes the connection to that the rpc client with id (sends `Close` callback to that client first?)
• RpcSend(int target, string method, [array args])
  - Calls a method on the rpc client with the id of `target`. Returns a request id.
• RpcBroadcast(string AuthenticationLevel, string method, [array args])
  - Calls a method on all connected rpc clients with >= authentication level, except it self. Returns request id.
• RpcRespond(int requestId, bool succcess, [array params])
  - Respond to RpcCall()

Callbacks:

• .RpcMethodCall(int requestId, int callerId, string method, array args)
  - Sent to the target client from a RpcSend()
• .RpcMethodReponse(int requestId, bool success, array params)
  - Sent to the sender of the request with the id `RequestId`.
• .RpcClientConnect(int id)
  - Sent to all rpc clients (kinda like PlayerConnect)
• .RpcClientDisconnect(int id)
  - Sent to all rpc clients (kinda like PlayerDisconnect)
• .RpcClientChanged(Struct SRpcClient)
  - Sent when info about the client changed (name, version, methods).

Code: Select all

struct SRpcClient {
    string Name,
    string Version,
    array Methods,
    bool CallbacksEnabled,
    string AuthenticationLevel
}

Identify() could be implemented into Authenticate - Authenticate(String user, String pass, [String name,[String version], [Array methods]])
Dunno how that would affect the return value of Authenticate()....

Example when a rpc client connects:
Assume that rpc client id:1 has already connected, authenticated and identified it self as `Controller` version `1.4`, and with one method `reboot`.

1. 2: (connects)
2. 1: Receives callback: RpcClientConnect(2)
3. 2: Calls method: Authenticate("SuperAdmin", "SuperAdmin", "SuperController", "0.9.1", array("reboot", "resync"))
4. 1: Receives callback: RpcClientChanged(+some struct+)
5. 2: Calls Method: EnableCallbacks()
6. 2: Calls Method: GetRpcClients() client 2 now knows that client 1 accepts the methods `reboot` and `resync`.

Example of RpcSend()/RpcReponse():

1. 1: Calls method: RpcSend(2, "resync"); Gets the RequestId... eg: 192.
2. 2: Receives callback: .RpcMethodCall(192, 1, "resync", []); RequestId: 192, method: "resync", no arguments.
3. 2: Calls method: RpcRespond(192, true) - responds with success, and then resyncs everything
4. 1: Receives callback: .RpcMethodResponse(192, true, [])

But of course, this is a lot more work for Nadeo, and there is more important stuff that has to be done...
I've just had this in my head for some time, and thought I'd just throw it out there. vadautink?