search

wish-wg / webrtc-http-egress-protocol

WHEP - WebRTC HTTP egress protocol draft
6 stars 7 forks source link

Better efficiency for Server Sent Events (via datachannel) #19

Open steely-glint opened 1 month ago

steely-glint commented 1 month ago

Server Sent Events are wasteful in a pure webRTC architecture. The events originate in the media server, then have to be passed internally to the correct HTTP server within the cluster(probably requiring some sort of permanent connection between the two and reducing mobility of both). The client then has to hold open a long poll (burning more ports and load balancer resources) in order to receive them after some unquantifiable delay.

All this when we have the WebRTC data channel right there. For Zero extra resource we can (optionally) send the events over a datachannel straight from the media server to the client at low latency.

The client code is almost unchanged as the SSE API looks a lot like a datachannel message (Both presumably modelled on websockets).

see PR https://github.com/wish-wg/webrtc-http-egress-protocol/pull/18 for possible wording.

murillo128 commented 1 month ago

I am not against the option of using datachannel for event handling, while I think it would need more work on how to negotiate them on the SDP and how to multiplex multiple message events over the same datachannel.

Also, not sure if I would like to delay the final version of the whep spec until we had agreed on a propossal for this or work on it as an extension to the spec.

steely-glint commented 1 month ago

Yes, sorry to bring this up so late. I did try and come up with a minimally invasive PR.

What else do you feel is needed in the SDP negotiation ? I think that since no other WHEP feature uses the data channel it is possibly enough to have both sides agree on m=application etc. Then the client doesn't have to open a data channel it can still use old style SSE if it wants.

I'm not sure I see the need for multiple data channels, the different events seem unambiguous on the wire to me, a simple pollyfill would do the trick I think.

murillo128 commented 1 month ago

I have already left some comments on the PR, but I think there are some question:

steely-glint commented 1 month ago

I've added some replies in the PR, but as far as the dc creation is concerned it should be in-band using DCEP and opened by the client - (I'll add this when/if I update the PR) - This allows a browser client to choose what it wants to do in javascript. (I don't believe this is true for SDP or out of band Data channels).

murillo128 commented 1 month ago

@steely-glint I haven't got time to look at this this week, would you mind presenting it at the next IETF meeting?

steely-glint commented 1 month ago

Next week ? or the one after that ?