[go: up one dir, main page]

Skip to content
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

fix: WebTransport stream now extends abstract stream #2514

Merged
merged 9 commits into from
May 1, 2024

Conversation

achingbrain
Copy link
Member
@achingbrain achingbrain commented Apr 30, 2024

The PR pulls all of the non-@fails/webtransport parts out of #2422

There's a lot of work that's been done to re-use existing libp2p code such as the abstract stream class which handles a lot more closing scenarios than the existing implementation so it would be good to get that in.

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation if necessary (this includes comments as well)
  • I have added tests that prove my fix is effective or that my feature works

The PR pulls all of the non-`@fails/webtransport` parts out of

There's a lot of work that's been done to re-use existing libp2p
code such as the abstract stream class which handles a lot more
closing scenarios than the existing implementation so it would be
good to get that in.
@achingbrain achingbrain requested a review from a team as a code owner April 30, 2024 15:04
Copy link
Member
@SgtPooki SgtPooki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not gonna pretend like my review is good enough to validate much, but I left some comments

if (!existsSync('./go-libp2p-webtransport-server/main')) {
await new Promise((resolve, reject) => {
exec('go build -o main main.go',
exec(`go build -o ${main} main.go`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these build files are being cleaned by npm run clean, which they probably should be

Copy link
Member Author
@achingbrain achingbrain Apr 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I want to remove this transport server entirely and just rely on precomplied binaries in the interop tests because they exercise more functionality which gives us more certainty and we don't need to be recompiling this unchanging go script over and over again.

packages/transport-webtransport/src/index.ts Outdated Show resolved Hide resolved
packages/transport-webtransport/src/muxer.ts Outdated Show resolved Hide resolved
Comment on lines +24 to +31
if (result.done) {
init.log('remote closed write')
return
}

async closeWrite (options?: AbortOptions) {
if (!writerClosed) {
writerClosed = true
if (result.value != null) {
this.sourcePush(new Uint8ArrayList(result.value))
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can value exist and the read be done? we should check for value first.

Copy link
Member Author
@achingbrain achingbrain Apr 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not exactly - if value exists and done is false, then value is the return value of the iterator, not a final value from the sequence.

See the iterator protocol docs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah. then i've incorrectly implemented iterators previously, or consumed some incorrectly implemented ones, because i've seen a sequence value and a done=true... good to know that's not a correct implementation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😬

@achingbrain achingbrain changed the title fix: update WebTransport implementation fix: WebTransport stream now extends abstract stream May 1, 2024
@achingbrain achingbrain merged commit de3f7ae into main May 1, 2024
22 checks passed
@achingbrain achingbrain deleted the fix/update-webtransport-implementation branch May 1, 2024 05:51
@achingbrain achingbrain mentioned this pull request May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants