Implement a UDP <-> WebRTC bridge (or other way of direct connection between rcssserver and a browser application)

[mateusfbsoares]

Thanks to @kawhicurry, we realized that we cannot make a direct connection between rcssserver (a native application) and websoccermonitor (a browser application) in order to enable real time visualization, since there is no proper support for UDP in the browser.

I believe 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 any browser-based application, solving this problem.

What do you think?

[hidehisaakiyama]

As discussed in the discord server, a simple proxy would be a reasonable solution.
And, the classic rcsslogplayer may be helpful for implementing the proxy feature because the classic logplayer works as a log server.
Of course, I can help to design the proxy feature.

[kawhicurry]

Hey, @hidehisaakiyama .

I've noticed that udp is deeply integrated with rcssserver. So a proxy inside rcssserver will be a much better solution.

And WebSoccerMonitor is intended to be a pure front application, so we may not going to write another isolated proxy program. Can we build a proxy as a module into rcssserver and make full use of librcss/net? If @mtfbs wants to implement WebRTC protocol, we can inherit class Socket and implement it easily.

I will try to write a demo later. Before that, I'd listen to your opinions.

Thank you for your help.

[hidehisaakiyama]

To be honest, I'm wondering why we need to integrate a proxy into rcssserver.

It is possible to develop a proxy as a module of rcssserver package. However, it causes more maintenance costs after that especially if it depends on the recent and unstable library. I think It would be preferred that a proxy module is developed and maintained as another package.

rcssserver is the core of the RoboCup soccer simulator. So, its portability and maintainability are some of the most important aspects. This is one of the reasons why rcssmonitor is separately maintained. Because the GUI toolkit is upgraded year by year, the maintenance cost of the server becomes higher if the monitor is integrated within the server.

The rcss/net library can be used from other projects. We can develop a proxy software package using that library. Then, the proxy can be called from rcsoccersim script. I think it's enough.

Please note the rcss/net library will be deprecated and removed because the standard C++ net library will be available in the near future. If you really need a network library, I recommend using boost::asio (The version of boost has to be 1.66 or higher).

[kawhicurry]

Thanks for your reply. I've acknowledged that rcssserver's portability and maintainability are some of the most important aspects. I will follow the instruction of building a proxy then call with scripts. And I will attempt to build the proxy software with standard C++ net library.

Again, thanks for your patient reply.

[mroa4]

Given that the script is standalone, why not use other programming languages. Like python or JS That they are easier to use and Likely do not need a lot of prerequisites?

[hidehisaakiyama]

Right.
We can develop a client (including a proxy) with any programing language and environment as long as we adhere to the protocol.
This is another reason the RoboCup simulator is separated into several modules.