libp2p
In-browser webrtc_websys can open stream, but can not accept stream from dialed peer (identify times out in golang basic host)
Summary
While trying to implement(https://github.com/lat-murmeldjur/weeb-3) an in-browser wasm client (to ethswarm bee network), the following behaviour was encountered. Dial to go-libp2p over webrtc-direct succeeds. Can open custom handshake stream which succeeds. After the handshake the other side tries to open a stream, which fails with identify failed: context timed out. My in-browser node has identify behaviour, also tried manually accepting off-band identify streams, also tried triggering identify push manually from browser, however, the result is in each case the golang side failing with this line while trying to open a new stream. Any help appreciated
Expected behavior
After .accept(P_PROTOCOL) and polling incoming streams, dialed node should be able to open stream towards browser node on the already existing connection.
Actual behavior
After .accept(P_PROTOCOL) and polling incoming streams, dialed (golang libp2p server) node times out with identify failed.
Relevant log output
No response
Possible Solution
Using websocket instead of webrtc with upgrade(V1), yamux and noise solved the issue. Is there a similar way to add a multiplexer to webrtc_websys transport?
Version
Latest git commit
Would you like to work on fixing this bug ?
Yes
How long is the timeout?
I'm troubleshooting browser webrtc right now, and seeing that the first usable DataChannel after the noise handshake takes about 10 seconds to open up.
however it might be interesting to note that I could already successfully write stream messages from the browser side immediately after handshake, the problem only occured when the go-libp2p side tried to open a new stream / protocol towards the browser (immediately after the browser-originated stream succeeded)
Yeah, what I'm seeing is an immediately available channel (likely the noise handshake) then 10 seconds of unavailability, then after 10 seconds the ongoing data channel is available.
I think there's an error in the handshake process causing a gap from 1 sec to 10 sec mark.
Try opening your stream 12 seconds after the NewConnection event and see if you still have the same issues
So actually the original identify failure was solved by updating the go-libp2p version on the server side to the latest. I also experience the 10 second delay between the dial and first protocol message exchanges which did not exist with websockets for example. It would be really nice to avoid having to wait for this.