webrtc: update str0m, fix multistream message decoding and encoding #441
Conversation
…cation, modify multistream protocol message, modify opening based on str0m api changes
| remaining = &tail[len..]; | ||
| if remaining.len() == 0 { | ||
| // During negotiation the remote may not append a trailing newline. | ||
| break; |
There was a problem hiding this comment.
Was this observed with smoldot integration?
There was a problem hiding this comment.
This was observed when testing against the libp2p native WebRTC transport. During negotiation, the libp2p native WebRTC transport doesn't append an extra newline.
| } | ||
|
|
||
| // For the `Message::Protocols` to be interpreted correctly, it must be followed by a newline. | ||
| header.push(b'\n'); |
There was a problem hiding this comment.
We could reach out to https://github.com/smol-dot/smoldot to align on the spec, then we could remove/simplify these functions.
We have diverged a bit from the spec, I wonder if this may break things down the line. Would the next message be interpreted correctly?
There was a problem hiding this comment.
We have @freddyli7 working on utilizing smoldot as a client to test against the libp2p server, as well as the litep2p server. We plan on getting it into litep2p-perf to run the performance behaviour. If things are incorrect in smoldot, we will create PRs upstream to fix them.
|
@timwu20 I released 0.11.1 |
3 participants
Changes