Unify driver protobuf protocol to SolarXR

[ImUrX]

We kinda have 2 different schemas currently being used, this needs an overhaul.

• [ ] Figure out how the whole protocol should look in flatbuffer
• [ ] Use only unix sockets in all OS for the driver IPC (supported since Insider Build 17063 on Windows 10)
• [ ] Work out if any extra is needed for Monado to have an easy time using this

Stuff that needs to be thought of:

• Because we are gonna still use sockets/pipes, we should use TCP directly, it will make everything easier by making sure messages are in order (which should still happen in UDP tbh) and take care of the concept of a "connection" which UDP doesn't have. The current implementation in Linux is TCP, so it won't require much change.

[rcelyte]

making sure messages are in order (which should still happen in UDP tbh)

I think you might be mixing things up here. TCP and UDP are protocols used for network sockets. Domain sockets will always be reliable and ordered regardless of whether they're configured as STREAM, DGRAM, or SEQPACKET (see https://stackoverflow.com/questions/13953912/difference-between-unix-domain-stream-and-datagram-sockets for more details).

Speaking for Monado's needs (as well as more generally), I believe SEQPACKET would make the most sense for IPC since it provides strong guarantees around message boundaries and prevents fragmentation, two things which I observed to have introduced non-trivial complexity with the existing STREAM based IPC in the OpenVR driver. Regardless, having the ability to communicate bone and tracker data natively without involving WebSockets will be invaluable to simplifying our implementation and cutting dependencies.

[ImUrX]

we can't use SEQPACKET as it's not supported in Windows.

Domain sockets will always be reliable and ordered regardless

Yes, I know that they are, thats why I say (which should still happen in UDP tbh).

I prefer not talking in POSIX standard as not every dev in our team knows it, we are gonna get into technicalities when they literally have the same behavior, so it's a lot simpler to call them in their network terms.

I know TCP and UDP are network protocols, but they have similarities in what they do in their equivalent counter-part in unix sockets as TCP is similar to STREAM, UDP is similar to DGRAM and SCTP is similar to SEQPACKET. I know pretty well how each works but the problem is to think also about compatibility not just for Linux but for other platforms.

EDIT: The reliability in datagrams is not a POSIX standard tho, it's something that Linux promises but I don't know if other implementors do the same :cry:

[ImUrX]

another thing proposed by @rcelyte is to use shm to not have to serialize a packet, send it, and deserialize it and instead just read stuff from each other, this sounds like a great idea tbh