Implement connection to RCSSServer and enable real-time game visualization

[mateusfbsoares]

I can think of 3 ways of doing this:

1 - Make the SoccerWebMonitor frontend able to get data directly from the RCSSServer as it runs on the same machine. (probably the best idea if possible)
2 - Provide the teams binary to the SoccerWebMonitor front-end. It sends it to the back-end and runs the teams and the RCSSServer on a docker image. Sends data in real time by websocket to the SoccerWebMonitor frontend and show it on the Monitor2D (even if not done at first, could be a nice feature on the long-term)
3 - Make a connection between the RCSSServer and the SoccerWebMonitor backend, and connect the backend to the frontend with a websocket.

[kawhicurry]

I support the first way and I've check its origin data format. It's easy to be parsed and transformed to graphic frames.
But I got a question here. What should WebSoccerMonitor be? I mean, a substitution of a monitor like rcssmonitor or soccerwindow2 (I'm a fan of it), or a complete system that enable us to play game online?

Another idea about docker, I believe one container should be viewd as one process. So run teams and rcssserver in one container might be a bad idea. To make teams and rcssserver run in separate containers, docker compose or kurbernetes might be helpful.

Finally, it's a interseting project. Hope it be better.

[mateusfbsoares]

Hello @kawhicurry, thank you for being interested in the project!

WebSoccerMonitor should be a substitution of a monitor like rcssmonitor or soccerwindow2. I think the idea of having a complete system that enable us to play a game online is promising, but due to the scope, I believe it should be a different project, in another repository, that could be created once WebSoccerMonitor is more mature.

I agree with your views on running teams and rcssserver in seperate containers with docker compose or kubernetes. This can be a great way of implementing a complete system to play the game online in the future.

I also think that the first way should be the implementation goal. That's great you already have an idea on how this could be done and it is easy to achieve. Please feel free to go further. Also, have you seen the discussions about introducing JSON as the monitor protocol in rcssserver? Supporting it should also be easy, so I think we could support both protocols. What do you think?

[kawhicurry]

@mtfbs
Thanks for reply.

I just checked that issue. JSON will make everything much easier! JS is really good at parse json. And I also notice Mr.Hidehisaakiyama just add supports for json-formation into their librcsc. He might already work on it, but there must be a lot of job to do among rcssserver and other monitor. When it's ready, a web monitor will be easy. Before that, we can support the old protocol first.

About the support of both protocols, Directly parse it with JS is one solution. It "seems" not difficult to do it. But I notice this project has using json as the default data formats. So a middleware that transform old formats to json could be a better solution.

This is my solution. Transform the old protocol into json protocol and send it to browser, browser parse it and show it. I'm not good at JS but I know how to implementate the middleware. Before that, I shoule learn ideas about Streaming media. It must be helpful. How's it?

[mateusfbsoares]

@kawhicurry

Awesome! I agree it should be easy to implement once rcssserver natively supports JSON, and I agree that we can work on supporting the old protocol first until then. I like the idea of transforming the old format to json; the only reservation I have is that, if possible, it should be done in the browser, because in order to ensure reliability and better compatibility as a tool, I want to make WebSoccerMonitor a frontend-only software (in order words, I want to completely remove the backend and have everything done in the browser).

In that sense, I'll be creating some issues related to the need of removing the current backend as soons as I can.

Do you think you can implement the transformation of the old format into JSON inside the browser? Maybe something like the monitor itself having an internal function that directly parses the data with JS and outputs it in JSON format so the monitor can display it with graphics.

I agree that learning ideas about streaming media could be helpful, maybe we can learn about other projects that do similar things.

[kawhicurry]

Here we go. https://github.com/rcsoccersim/rcssserver/releases/tag/rcssserver-17.0.0

[kawhicurry]

I made some attempt today and found a big problem.
If we need to do everything in the browser, how to send UDP packages?

[mateusfbsoares]

It is indeed a big problem, thank you for realizing this.

I think one solution would be to implement a UDP <-> WebRTC bridge inside rcssserver as described in this answer using a library such as libdatachannel. In my understanding, this would allow for direct connectivity between rcssserver and WebSoccerMonitor. I have created an issue on rcssserver about this.

[mateusfbsoares]

We discussed on the 2D League discord server, and came to the conclusion that implementing the UDP <-> WebRTC bridge would be very difficult at the moment. The proposed solution for the short term is to build a proxy inside rcssserver.

[kawhicurry]

I've checked WebRTC when I made attempt yesterday and I've read the source code of rcssserver. I have to admit that it's much easier to implement a proxy than refactor the rcssserver. I wrote one with python in few lines. It changes udp to tcp.

##!/usr/bin/python3
# client.py

import socket

udp = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
tcp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
tcp.bind(('127.0.0.1', 7000))
tcp.listen(1)
tcp2, addr = tcp.accept()
buf = tcp2.recv(40960)
# print(buf.decode('utf-8'))
udp.sendto(buf, ('127.0.0.1', 6000))
while True:
    buf2 = udp.recv(40960)
    tcp2.send(buf2)

#!/usr/bin/python3
# client.py

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 7000))
# buf = input()
buf = '(dispinit version 5)'
msg = s.send(buf.encode('utf-8'))
while True:
    print(s.recv(40960).decode('utf-8'))

So I think the problem now is "where should we put the proxy?"
I will save my words and give my solution.

I won't forget WebSoccerMonitor is going to be a pure front-end program.So the proxy should be built into librcss. Then we can start it with two methods: as a isolated software (mainly for debug) and as a module for rcssserver (start with option). More details should be discussed in rcssserver's issue, we are supposed to respect the ideas of developer of rcssserver. Before that, we can start parse json with JS now.

[mateusfbsoares]

I agree we should discuss this implementation further in the rcssserver's issue, and I think your proposed solution is a good idea. I also agree we can start parsing json with js now. I've created an issue for tackling this specific problem.

[kawhicurry]

A small demo here. https://github.com/kawhicurry/WebSoccerMonitor-plain