Please give us bidirectional TCP OSC
SenkyDragon
UDP OSC is not suitable for many use cases because:
* The process breaks entirely if vrchat fails to receive the oscquery broadcast packet from the client
* The process breaks entirely if the client fails to receive the oscquery broadcast packet from vrchat
* The process is complicated and not suitable to be implemented by any developer comfortable with a standard TCP connection process
* Getting the initial state from oscquery over http is not atomic, which means you can desync while simultaneously receiving updates from OSC
* The avatar's status isn't even guaranteed to be consistent at all because the UDP OSC packets can be dropped
I propose the following:
* Please open OSC on TCP port 9000 and announce over zeroconf. If 9000 is not available, choose a dynamic fallback port.
* Multiple users should be able to connect to the TCP port simultaneously.
* When a user connects, immediately send them a full OSC packet containing the full current state of the avatar with all keys.
* Allow OSC updates to be sent bidirectionally. VRChat and the OSC client should both be able to send OSC updates through the single TCP socket.
Log In
Yewnyx
For this summary I'm not specifically talking about TCP vs UDP purely for reliable transport delivery, I am also talking about the ability to reason about OSC information being in a known state.
When integrating with OSC, to get to a known state of bidirectional communication:
- The workflow can fail early if VRChat fails to receive the OSCQuery Zeroconf advertisement from the app
- The workflow can fail early if the app fails to receive VRChat's zeroconf query broadcast
- The workflow is difficult to implement in a standalone project (i.e. other language or not using the same library or not in a configuration actively tested and supported by VRChat)
- Either the non-atomicity of avatar updates or the non-serialized (i.e. possibly out of order) nature of the avatar updates can cause inconsistent behavior.
That is to say, OSC updates can arrive out of step with OSCQuery updates, and thus result in inconsistent states when reliable or mostly-reliable broadcasts are needed. In the case that reliable communication is needed, delivering the information via a reliable TCP-based handshake over the same transport as the OSC packets themselves is desirable.
-----
It's tedious and time-consuming to layer reliable transport on top of unreliable (it's a good piece of infrastructure to do it of course - SCTP does it, but it can be difficult to deploy), so delivering complex metadata with the same transport as _unreliable_ data is understandably fraught with problems, and it's not hard to understand how OSCQuery and OSC complement each other for use cases in which reliable information about unreliable (as in packets-droppable) information is desired.
However, for complex creations, particularly those which might reasonably rely upon in-order, reliable updates rather than timely, high-throughput delivery-optional updates to i.e. correctly update the animators' state machines, it is a lot more important to serially and reliably deliver and process updates. Importantly, this flow is also significantly easier to implement for any application without the requirement for high throughput.
For this reason, I think it may be important to consider how to better service the applications which consume/produce OSC packets with these requirements, as - outside the external tracking device use case - the remainder of applications may strongly desire a lower-throughput reliable transport free of race conditions in avatar state delivery.