Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify driver protobuf protocol to SolarXR #895

Open
3 tasks
ImUrX opened this issue Nov 5, 2023 · 2 comments
Open
3 tasks

Unify driver protobuf protocol to SolarXR #895

ImUrX opened this issue Nov 5, 2023 · 2 comments
Labels
Area: SteamVR Driver Related to the SteamVR Driver Priority: Normal The default priority Type: Discussion Further information is requested Type: Enhancement Adds or improves a feature

Comments

@ImUrX
Copy link
Member

ImUrX commented Nov 5, 2023

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.
@ImUrX ImUrX added Type: Discussion Further information is requested Priority: Normal The default priority Type: Enhancement Adds or improves a feature Area: SteamVR Driver Related to the SteamVR Driver labels Nov 5, 2023
@rcelyte
Copy link

rcelyte commented Jun 9, 2024

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
Copy link
Member Author

ImUrX commented Jun 9, 2024

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 😢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: SteamVR Driver Related to the SteamVR Driver Priority: Normal The default priority Type: Discussion Further information is requested Type: Enhancement Adds or improves a feature
Development

No branches or pull requests

2 participants