-
Notifications
You must be signed in to change notification settings - Fork 24
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
Conversation
53036d9
to
ce08921
Compare
ce08921
to
4883ee4
Compare
Can this be added as an optional feature? |
Ok(future) => Ok(MultiListenFuture::Ws(future)), | ||
Err(e) => Err(e), | ||
}, | ||
TransportType::Wss => Err(TransportErrorKind::NotSupported(address)), |
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.
How about just removing these two transport types from the enum?
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.
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 { |
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 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.
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.
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.
7eb152f
to
3d38cc3
Compare
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); |
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.
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()); |
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.
I will use another PR to upgrade the toolchain and modify the related code
2645b30
to
3d38cc3
Compare
Add support for WebSocket, now web applications can communicate directly with each other.