I have tried to connect to a simple socket.io server with what seem to be the only two C++ socket.io libraries on the net, socket.io-clientpp (the one you originally mentioned) and socket.io-poco. Neither is able to connect to a server using socket.io 1.0 and development for both seems to have ended long ago. As it stands, the nearest alternatives (in terms of interfacing with OpenROV’s existing code without modifying it) are to try and implement socket.io communication on your own using a C++ websocket library or write a proxy application in a language that has support for socket.io 1.0, such as Java. The first solution requires a decent bit of effort (evidenced by the fact that it doesn’t already exist) and the second is just a lackluster solution in general, since you’ll either have to reinvent the functionality that socket.io provides in the interface between your C++ program and your proxy or forego having it. You could also create a proxy on the OpenROV side using a websocket library that is more straightforward to interface with on the C++ side, however this has some of the same drawbacks as creating the proxy on your client-side.
While websockets and socket.io are great for enabling simple, event-driven communication in the domain of web development, apps, and similar families of technology, there is little to no support for the average C/C++ user. The vast majority of robotics libraries, research algorithms, and sensor interfaces are natively written in C or C++, and you will probably find that the typical users of these software packages are not familiar with web technologies or communication frameworks. With that in mind, I would say that if you want to make the OpenROV more “open” in the existing ecosystem of robotics software, you may want to consider choosing a more interoperable communication framework. For the purpose of trying to integrate an OpenROV vehicle into the research I’m doing at work, the roadblocks and cost/benefit impacts of not being able to easily interface with the OpenROV software with our existing software drive the decision to just use our own software for both communicating with and controlling the vehicle and enabling autonomous operation.
In the meanwhile, I’ll keep my eyes peeled for other methods, libraries, etc to try and bridge this gap.