warhawkreborn / connector_cli

Connector to allow discovery of servers (CLI version)
10 stars 5 forks source link

Implement small webserver to give status #10

Open davidsummers opened 4 years ago

davidsummers commented 4 years ago

In issue #2 you mentioned:

My original idea was to port the unix version to windows (should be pretty simple) and implement a small webserver in it to serve a UI. This would have some benefits over a native gui app:

Ability to use UI from a different device than host Run on headless without modifications Plattform independent gui design

What are you thinking of in the way of a library to implement the web server and what kind of information would be presented to the user?

Thalhammer commented 4 years ago

I think the most important information would be the following:

Also it might be a good idea to add the following:

As it will be the primary solution for people hosting, we might also add some more advanced features in the future:

While the first 3 features reason should be obvious (spam protection) the last two have a pretty simple reason as well. We would like to decipher the protocol to implement features like

However to do so we need to understand (and intercept the encryption of the protocol) and having captures of the data going back and forth would really help here. They of course require intercepting the traffic, but if the server is running 24/7 it should not be a problem to do so. That said it should of course be optional.

davidsummers commented 4 years ago

Have you already picked out a web server C/C++ library you would like to use?

I googled and found things such as:

  1. Mongoose (https://github.com/cesanta/mongoose)
  2. libmicrohttpd (http://www.gnu.org/software/libmicrohttpd/)
  3. libevent (https://www.monkey.org/~provos/libevent/doxygen-1.4.10/evhttp_8h.html)
  4. webem (https://www.codeproject.com/Articles/29290/A-C-Embedded-Web-Server)
  5. uws (MicroWebSockets) (https://github.com/uNetworking/uWebSockets)
  6. muduo (https://github.com/chenshuo/muduo) ... just to name a few I found within a couple of minutes.

Thoughts?

Thalhammer commented 4 years ago

I did not select one already but I did ready examples of uws while evaluating different Websocket libraries. However I choose websocket++ in the end.

I think we don't need a lot of the features and in order to keep dependencies down I think we might also consider writing a tiny HTTP1.0/1.1 implementation from scratch based on sockets directly. We don't need TLS or high performance, so a ~300 line c++ server which only depends on sockets seems like a nice solution for me.

That said we already depend on SSL and libcurl anyway, so anything that does not add a lot of bloat might be fine.

davidsummers commented 4 years ago

Wow, that is a very interesting list of features for the WarHawkReborn built-in web server.

To implement a lot of them then the warhawkreborn would need to advertise itself and be the recipient of the port 10029 packets through the router instead of the PS3 and then pass them on to the PS3, whereas as it stands at the moment, warhawkreborn is "on the side" and not "inbetween" the packets to the PS3.

I like all those features. Sounds like a good challenge. It will take a while to implement.

I think first the built-in web server should be implemented and then slowly start adding those other features.

There appear to be two "modes" of operation:

Question 1: What would be good names for those two different modes? Question 2: I wonder what extra latency the "in the middle" mode will take and whether that will be significant in playing games?

Thalhammer commented 4 years ago

What would be good names for those two different modes?

Maybe proxy and announcement mode ?

I wonder what extra latency the "in the middle" mode will take and whether that will be significant in playing games?

I doubt it. Using this mode would have it function basically like xlink and I don't remember anyone complaining about latency on XLink. As long as we just track connections and capture packages there should not be any load at all and even once decrypt packages, I am pretty sure any pc made in the last 10 years should be able to handle anything a PS3 made in 2007 is able to throw at it.

davidsummers commented 4 years ago

I'm getting ready to start in on the initial web-server development.

Just to be clear, you said you liked either:

  1. websockets++
  2. Custom webserver.

Is that correct?

I'll take a look at doing it both ways.

My current plan is to just have a small initial web server which just shows the list of servers to begin with. Later we can start adding more features.

Does that sound OK?

davidsummers commented 4 years ago

I've got a working web server (with websockets capability) in PR #15.

I've tested on CentOS-7, Raspberry PI, MacOS, and Windows.

Please let me know what you think.

Binaries are at https://summersoft.fay-ar.us/pub/games/warhawk URL.

davidsummers commented 4 years ago

A bunch of internal improvements/simplifications have been made and I've now verified that the servers get deleted from the internal list when they go away.

I just now verified 908ed44 builds on all platforms.

I've been running each new version on my own home system router on CentOS-7, and also periodically on MacOS, Raspberry PI, and doing most development work on Windows.

I've of course been using Visual Studio 2019 Community Edition on Windows and latest QT Creator on MacOS and Linux for the IDEs.

Installers are at https://summersoft.fay-ar.us/pub/games/warhawk URL.

I'll keep adding improvements as I think of them, but I would like for you to take a look at what is there and tell me what you think.

Thalhammer commented 4 years ago

Looks good, however I had to replace with experimental/filesystem on my system (gcc v7.4) which might confuse some people. We should check for this and alias either std::filesystem or std::experimental::filesystem

davidsummers commented 4 years ago

Hmm, which distribution are you using?

I would think that most current distributions would be up-to-date with GCC 8 or higher.

That is required to use all the "standard" C++17 stuff.

If you want to support a lower standard we can, we just lose all the neat standard C++ filesystem stuff.

If you do want to support a lower standard, should the whole code use that lower standard or should we conditionally compile different code depending on which standard/compiler?

Ideally, since this is a fairly "new" project we could assume that people would use the latest C++17 or do you want to expand the platforms to ones that don't (yet) support C++17?

Let me know what you think.

Thalhammer commented 4 years ago

I used Elementary OS 5.0 at the time (Ubuntu 18.04 based) I'll have to recheck with my current OS.

davidsummers commented 4 years ago

Oh, there you are! Glad you are OK.

OK, please let me know what you find out.

It should be fairly easy to support multiple distributions.