search

pion / webrtc

Pure Go implementation of the WebRTC API
https://pion.ly
MIT License
13.78k stars 1.66k forks source link

Writing to a detached datachannel doesn't error when it disconnects #1284

Open cryptix opened 4 years ago

cryptix commented 4 years ago

This feels like another aspect of of #903 but wasn't sure and did not want to derail conversation.

Your environment.

What did you do?

I worked through most of the examples like ortc and datachannel(-detach) to get an idea who I could integrate webrtc in our existing (go-)ssb stack. Most of the heavy lifting would be much easier with io.ReadWriteCloser.

What did you expect?

An error from writing to the detached pipe as soon as the connection disappears.

Ps: the ICE state reflected this but the RWC pipe was unaffected.

What happened?

It just kept writing. Read also didn't error out.

Side question:

How does the flow control example relate to the detached feature? With some extra work I could use the message oriented callback api but it would mean dropping support for current/legacy tech (muxrpc)

Sean-Der commented 4 years ago

@cryptix that's a good question, I don't know the answer.

It is copying the behavior of DataChannels, and not return an error when ICE has gone to disconnected (or failed). Which seems nice to me! A user can just write and we will buffer (and then send when ready). If the user wants to pace their sending they can measure back pressure.

The other hard thing is breaking backwards compatibility and start returning errors.

I am happy to make this is a user configurable behavior though! DetachedErrorOnDisconnected or something like that.

@backkem thoughts/opinions?

backkem commented 4 years ago

Maybe we do this since the disconnected state doesn't have to be final. You can still reconnect. AFAIK the reader does return an error when you close the transports. If you want this to happen you can listen for the disconnected event and close the peer connection. That should wind down and release all readers by returning an error.