[WIP] Fix eof on read #18
Conversation
datachannel.go
Outdated
| @@ -175,15 +175,8 @@ func (c *DataChannel) Read(p []byte) (int, error) { | |||
| func (c *DataChannel) ReadDataChannel(p []byte) (int, bool, error) { | |||
| for { | |||
| n, ppi, err := c.stream.ReadSCTP(p) | |||
| if err == io.EOF { | |||
There was a problem hiding this comment.
Are we required to lose this? It's defined in the data channel spec:
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.7
Closing of a data channel MUST be signaled by resetting the
corresponding outgoing streams [RFC6525]. This means that if one
side decides to close the data channel, it resets the corresponding
outgoing stream. When the peer sees that an incoming stream was
reset, it also resets its corresponding outgoing stream. Once this
is completed, the data channel is closed.
There was a problem hiding this comment.
Hmmm. I may have read it wrong.
When the peer sees that an incoming stream was reset, it also resets its corresponding outgoing stream.
In this sentence, "the peer" is referred to SCTP/DataChannel entity or application?
In TCP, when a node receives FIN, it goes into CLOSE_WAIT state in which application can still send data, so how I read made sense but now I am not sure: https://upload.wikimedia.org/wikipedia/commons/f/f6/Tcp_state_diagram_fixed_new.svg
If we did not make this change, TestEOF (in pion/webrtc) would fail.
There was a problem hiding this comment.
Actually, with non-detach case, if a node receives EOF on a datachannel, OnClose callback is made. I guess it is a bit weird to have the channel actually half-open after OnClose is made... How about enabling this half-open (CLOSE_WAIT) state only with detached datachannel?
There was a problem hiding this comment.
There was a problem hiding this comment.
rfc6458 does not seem to assume rfc6525 (reconfig) because it is true that SCTP (rfc4960 alone) only has Shutdown or Abort of association. rfc6525 is pretty close to allow TCP socket's SHUT_WR operation, but again the above sentence is still a question...
There was a problem hiding this comment.
Regarding half-open (CLOSE_WAIT) state: a data channel is defined as bidirectional: https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.4
Data channels are defined such that their accompanying application-
level API can closely mirror the API for WebSockets, which implies
bidirectional streams of data and a textual field called 'label' used
to identify the meaning of the data channel.
Same on the protocol level: https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09#section-4
The Data Channel Establishment Protocol is a simple, low-overhead way
to establish bidirectional Data Channels over an SCTP association
with a consistent set of properties.
Therefore, It seems unlikely that this use-case would come up.
There was a problem hiding this comment.
Re-opened. @enobufs let us know if you agree.
Relates to pion/webrtc#652
Description
Currently, on receipt of EOF pion/datachannel closes the outgoing channel.
It is the requirement from libp2p that even EOF is received on a datachannel, the datachannel be available for write until the app calls Close on the datachannel. (in the context of detached mode)
The sctp branch this PR uses solves EOF related problems. This fix in datachannel module will complete the whole issue around EOF discussed in pion/webrtc#652.
Reference issue
Fixes pion/webrtc#652
TODO
Before merging this, we will need to tag sctp this PR depends on.