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

feat: support websocket transport #257

Merged
merged 2 commits into from
Sep 15, 2020
Merged

feat: support websocket transport #257

merged 2 commits into from
Sep 15, 2020

Conversation

driftluo
Copy link
Collaborator

@driftluo driftluo commented Sep 2, 2020

Add support for WebSocket, now web applications can communicate directly with each other.

@driftluo driftluo requested review from TheWaWaR, a team and doitian September 2, 2020 01:48
@driftluo driftluo force-pushed the support-websocket branch 2 times, most recently from 53036d9 to ce08921 Compare September 4, 2020 11:15
@doitian
Copy link
Member

doitian commented Sep 9, 2020

Can this be added as an optional feature?

multiaddr/src/protocol.rs Outdated Show resolved Hide resolved
Ok(future) => Ok(MultiListenFuture::Ws(future)),
Err(e) => Err(e),
},
TransportType::Wss => Err(TransportErrorKind::NotSupported(address)),
Copy link
Member

Choose a reason for hiding this comment

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

How about just removing these two transport types from the enum?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

How about just removing these two transport types from the enum?

Explicit errors are better than strange behaviors, such as tls address recognized as tcp

Err(e) => Err(e),
},
TransportType::Wss => Err(TransportErrorKind::NotSupported(address)),
TransportType::TLS => Err(TransportErrorKind::NotSupported(address)),
}
}
}

pub enum MultiListenFuture {
Copy link
Member

Choose a reason for hiding this comment

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

This is a discussion but not change suggestion.

It's a bit tedious to add these manual dispatching code. Also it is not flexible enough to support 3rd-party transport.

In my opinion, it is easier if the transport has a clear interface, and a new transport only needs to implement the interface.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

How to be simple and abstract at the same time, that's the challenge.

I don't see a good solution at the moment. The good news is that here are the details of the library's internal implementation, which is sufficient for use at the moment.

src/transports/ws.rs Outdated Show resolved Hide resolved
src/transports/mod.rs Outdated Show resolved Hide resolved
Comment on lines +320 to +323
buf[..n].copy_from_slice(self.recv_buf[..n].as_ref());

// drain n bytes of recv_buf
self.recv_buf = self.recv_buf.split_off(n);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
buf[..n].copy_from_slice(self.recv_buf[..n].as_ref());
// drain n bytes of recv_buf
self.recv_buf = self.recv_buf.split_off(n);
buf[..n].copy_from_slice(self.recv_buf.drain(..n).as_slice());

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I will use another PR to upgrade the toolchain and modify the related code

@driftluo driftluo merged commit 9ee2e8c into master Sep 15, 2020
@driftluo driftluo deleted the support-websocket branch September 15, 2020 02:42
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.

3 participants