-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement WebRTC messages framing #2896
Merged
Merged
Changes from 21 commits
Commits
Show all changes
23 commits
Select commit
Hold shift + click to select a range
30ee30b
Wrap substreams within a struct
tomaka b9e00a1
Move the substream id inside of the struct
tomaka 0106fb8
Make the substream extractable
tomaka bb7ab99
Implement the framing
tomaka a6685d3
Missing a continue_looping
tomaka e10047b
Some tweaks
tomaka 2e010f4
CHANGELOG
tomaka a1775c3
Fix build
tomaka b892594
Bump write buffer to 16kiB
tomaka bca2011
Add framing around handshake
tomaka 77aa3f2
Improvements to the networking task
tomaka b5f9ef1
Fix wrong decoder ugh
tomaka 72c8175
Don't use all_consuming
tomaka 091a177
Wrong encoding too 🤦
tomaka 5624158
Fix wrong Noise initiator
tomaka 2fb0b14
Fix not inserting substreams in out_in_substreams_map
tomaka 07b4e06
Don't loop if the substream has been reset
tomaka 27a9be1
Move wake_up_after inside of the loop
tomaka 8a0dc27
Change max message size in SDP
tomaka ad6a083
Small comments fix
tomaka ba593a9
More fixing
tomaka 6ad4bf1
Revert the lite thing
tomaka 6c1b162
Merge branch 'main' into messages-framing
mergify[bot] File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -256,29 +256,29 @@ export function start(options?: ClientOptions): Client { | |
"v=0" + "\n" + | ||
// Identifies the creator of the SDP document. We are allowed to use dummy values | ||
// (`-` and `0.0.0.0`) to remain anonymous, which we do. Note that "IN" means | ||
// "Internet". (RFC8866) | ||
// "Internet" (and not "input"). (RFC8866) | ||
"o=- 0 0 IN IP" + ipVersion + " " + targetIp + "\n" + | ||
// Name for the session. We are allowed to pass a dummy `-`. (RFC8866) | ||
"s=-" + "\n" + | ||
// Start and end of the validity of the session. `0 0` means that the session never | ||
// expires. (RFC8866) | ||
"t=0 0" + "\n" + | ||
// A lite implementation is only appropriate for devices that will | ||
// *always* be connected to the public Internet and have a public | ||
// A non-lite implementation is only appropriate for devices that will | ||
// always be connected to the public Internet and have a public | ||
// IP address at which it can receive packets from any | ||
// correspondent. ICE will not function when a lite implementation | ||
// correspondent. ICE will not function when a non-lite implementation | ||
// is placed behind a NAT (RFC8445). | ||
"a=ice-lite" + "\n" + | ||
// A `m=` line describes a request to establish a certain protocol. | ||
// The protocol in this line (i.e. `TCP/DTLS/SCTP` or `UDP/DTLS/SCTP`) must always be | ||
// the same as the one in the offer. We know that this is true because we tweak the | ||
// offer to match the protocol. | ||
// The `<fmt>` component must always be `pc-datachannel` for WebRTC. | ||
// The `<fmt>` component must always be `webrtc-datachannel` for WebRTC. | ||
// The rest of the SDP payload adds attributes to this specific media stream. | ||
// RFCs: 8839, 8866, 8841 | ||
"m=application " + targetPort + " " + "UDP/DTLS/SCTP webrtc-datachannel" + "\n" + | ||
// Indicates the IP address of the remote. | ||
// Note that "IN" means "Internet". | ||
// Note that "IN" means "Internet" (and not "input"). | ||
"c=IN IP" + ipVersion + " " + targetIp + "\n" + | ||
// Media ID - uniquely identifies this media stream (RFC9143). | ||
"a=mid:0" + "\n" + | ||
|
@@ -287,6 +287,7 @@ export function start(options?: ClientOptions): Client { | |
// ICE username and password, which are used for establishing and | ||
// maintaining the ICE connection. (RFC8839) | ||
// MUST match ones used by the answerer (server). | ||
// These values are set according to the libp2p WebRTC specification. | ||
"a=ice-ufrag:" + remoteCertMultibase + "\n" + | ||
"a=ice-pwd:" + remoteCertMultibase + "\n" + | ||
// Fingerprint of the certificate that the server will use during the TLS | ||
|
@@ -303,8 +304,9 @@ export function start(options?: ClientOptions): Client { | |
// (UDP or TCP) | ||
"a=sctp-port:5000" + "\n" + | ||
// The maximum SCTP user message size (in bytes) (RFC8841) | ||
"a=max-message-size:100000" + "\n" + | ||
// A transport address for a candidate that can be used for connectivity checks (RFC8839). | ||
"a=max-message-size:16384" + "\n" + // TODO: should this be part of the spec? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. subject to a change, but yes! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
// A transport address for a candidate that can be used for connectivity | ||
// checks (RFC8839). | ||
"a=candidate:1 1 UDP 1 " + targetIp + " " + targetPort + " typ host" + "\n"; | ||
|
||
await pc!.setRemoteDescription({ type: "answer", sdp: remoteSdp }); | ||
|
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
??? This was a copy from the specification. Did something change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
? The specification doesn't contain this text. It's me who wrote it. It has a mistake in it, it says that lite implementations are only for publicly-accessible devices. But no, it's non-lite implementations that are for public devices. We're not a public device, so we use the lite implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Certain ICE agents will always be connected to the public Internet
and have a public IP address at which it can receive packets from any
correspondent. To make it easier for these devices to support ICE,
ICE defines a special type of implementation called "lite" (in
contrast to the normal full implementation). Lite agents only use
host candidates and do not generate connectivity checks or run state
machines, though they need to be able to respond to connectivity
checks." https://datatracker.ietf.org/doc/rfc8445/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By specifying
ice-lite
in server's SDP (that we're pretending we've received through some channel, but instead construct manually), we're saying that server is publicly accessible.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest this text doesn't make sense to me no matter whether it says "lite" or "not lite", so I've just reverted it 🤷