- The example starts normally, and usually it is possible to send and receive few messages.
- But then one peer observes remote close write event and overall 'close' on the chatStream.
- The other peer have no idea about that and is still able to write some data to the channel (but such data will be lost somewhere).
The connection interruption seems to be independent of time between consequent messages (probably not a consequence of some timeout) and of size of the messages (probably not overflow).
I turned tracing and debug logs on and observed no FIN / FIN_ACK exchanges related to such interruptions from either side. Replacing yamux with mplex also does not prevent that behavior.
When I removed ping service from clients, the interruption seemed to occur later, so the stream stays for longer. It may be just a coincidence (that way I tried to reduce number of connection reuse requests).
Also there are rare sessions when the interruption does not occur.
The issue occurs in firefox (ver 145), but not in chromium ( 143.0.7499.169 )
I also found that https://bugzilla.mozilla.org/show_bug.cgi?id=1603887 and tried to use applicable fix (setting dummy 'datachannel' event listener on every connection), but it didn't work
package-lock.json