ACE.Server needs to expose an API for diagnostics and other information

[Mag-nus]

Bug Report or Feature Request (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ X] feature request

Desired functionality.

The ACE project is growing rapidly and we need the ability to expose diagnostic information from ACE.Server for 3rd party tools to access.

Such data exposed might be:
Number of players connected
Player locations
Landblock states
Chat
Physics Information
Debugging

We used to have an ACE.Diagnostics project that collected information from ACE.Server, but that was removed because the implementation required ACE.Server to have a direct reference to the ACE.Diagnostics project.

ACE.Server should not require a direct reference to the 3rd party tools collecting the information.

Perhaps an ACE.Diagnostics library is created that is used for the API.

We need someone to help us model the base implementation so that we can build on it as the project grows.

[EvanMerlock]

This API should add the ability for client programs to communicate with the server. (begins with admin applications, end goal - any service can communicate with live server)

Transport Protocols: Named Pipes/UDP?
Serialization Model: WCF for configurable backends.

Brainstorming:
LINQ queries for subscription? (query from client would subscribe and then be notified upon change)
Info should seem like queryable interface and less 'subscribe to specific channels'
Webhooks?
Dynamic selection on which things to observe

Perhaps have a request/response type between client and server.
Can't rush the server with requests (request spam blocking)

[gmriggs]

Possible technologies / libraries mentioned:

System.Reactive / ReactiveUI - http://reactivex.io/ (gmriggs, initial investigation seemed like Dictionary support w/ updates was not an exact fit)

LINQ expressions - https://msdn.microsoft.com/en-us/library/system.linq.expressions.expression(v=vs.110).aspx, https://jacksondunstan.com/articles/3199 (fartwhif, mentioned that he used these to build a similar API)

WCF - https://docs.microsoft.com/en-us/dotnet/framework/wcf/whats-wcf (Magnus, contract-based model)

OData Open Data Protocol - https://en.wikipedia.org/wiki/Open_Data_Protocol, https://stackoverflow.com/questions/15154469/is-there-a-odata-query-to-linq-where-expression-odata-to-linq (parad0x, looks very promising. LINQ support, and starts to add more functionality for REST WebAPI)

[amoeba]

I'd find the current count of players useful for TreeStats. Since TreeStats currently gets player counts from my plugin (which gets it from from Decal CharacterFilter), the information I have requires players to run the plugin and suffers staleness issues related to the server protocol only sending the player count at login (I'm not sure what ACE's behavior is here). I think I'd find a public HTTP API the most useful for getting this info. Just my 2c.

[EvanMerlock]

It seems like there is 2 usages for this

• high perf/throughput data (live physics/landblock/player loc data)
• lower throughput data (player count, admin control/tooling, slower updated player loc data)

It could be handled via Websockets for the lower throughput data and UDP for the high throughput data.
Another issue is overloading the server. Too many apps requesting too much high throughput data could cause a server slowdown, so it would either need to be limited OR another solution would need to be found for the high throughput data.

[fartwhif]

For remotely querying EF and EF core with System.Linq Remote.Linq (MIT) has been amazing.

[fartwhif]

working on a Web API that satisfies the stated dependency requirements

#1390 (old link)

#1542 (plugin system)

#1629 (API plugin)

[Mag-nus]

An approach I've been working on is to use Prometheus to serve data: https://github.com/Mag-nus/ACE/tree/prometheus

It uses this library: https://github.com/prometheus-net/prometheus-net

An example of how metrics are provided is here: https://github.com/Mag-nus/ACE/blob/prometheus/Source/ACE.Server/Program_Metrics.cs