search

cwi-dis / VR2Gather

Unity application framework for immersive social VR
MIT License
2 stars 6 forks source link

Abstracting out media transport protocols #150

Closed jackjansen closed 3 months ago

jackjansen commented 5 months ago

I think it would be a good idea to "abstract out" the transport protocols (currently TCP, SocketIO, Dash and WebRTC underway).

Here's the basic idea. Comments please.

First the transport protocol handlers in VR2Gather become structured like the user representations are now. The implementations get a static initialiser that registers the implementation class with a VRTTransportProtocolRegistry by name. All transport protocol classes derive from some VRTAbstractTransportProtocol, and that's the class that is used everywhere else in the code. The list of names in the transport protocol popup menu in Create Session would also be populated from the VRTTransportProtocolRegistry.

Once this is implemented @jvdrhoof doesn't have to clone the VR2Gather repo for development: he can simply create a VRTApp and call the right registration method there.

Next step is that the Orchestrator gets an API to allow getting the list of supported transport protocols. Probably the code on the side of the orchestrator could be structured along similar lines (with a registry by name for supported transport protocols). For a specific combination of orchestrator/VR2Gather the list of supported protocols would then be the intersection of the two lists. tcp would always be supported (because the orchestrator doesn't have to do anything for it).

This also seems to be a good reason to structure the socketio handling similar to the dash and webrtc protocols: have it be handled by a separate SFU-like process, on a different port. This, in turn, means that we can eventually replace the orchestrator by something else.

Edit: that paragraph is no longer our current thinking: we will provide a TCP SFU and possibly later also a message queue sfu.

jackjansen commented 5 months ago

I would like to also assign @jvdrhoof but that seems to be impossible?

jackjansen commented 4 months ago

Have to fix #157 first to remain sane.

ireneviola commented 3 months ago

Is this needed for June 3rd (Tom doesn't think so), or is it a nice-to-have?

jackjansen commented 3 months ago

Is this needed for June 3rd (Tom doesn't think so), or is it a nice-to-have?

These are potentially all interrelated. But I'm not sure: @troeggla thinks that it may be possible to have the alternative socket.io protocol also handle large packets, therefore it could be a drop-in replacement for BestHTTP, therefore all these issues become non-critical.