search

denoland / fastwebsockets

A fast RFC6455 WebSocket implementation
https://docs.rs/fastwebsockets/
Apache License 2.0
827 stars 60 forks source link

split stream, what is latest status of feature `unstable-split`? #64

Open so-schen opened 7 months ago

mmastrac commented 7 months ago

It's been in use in Deno for a few months now, I think and it's been stable. I'm not sure if we'll tweak the API in the future to make it a little more ergonomic, but the feature definitely works.

so-schen commented 7 months ago

@mmastrac, by reading the impl, it seems to me the read frame is not Cancel safe. Am I correct?

mmastrac commented 7 months ago

I suspect if you are using automatic pong and automatic close, those methods are not cancellation-safe. We probably need to have a full poll-read/poll-write set of interfaces to ensure that.

so-schen commented 7 months ago

FragmentCollector::read_frame() which use async fn parse_frame_header does not remember the read pointer, so if it is canceled in the middle, the data read from tcp stream will be forgotten in next call, because re-enter the read_frame, we start from read from index 0

I am not familiar with websocket wired-protocol, I wondering if this is potential risk

BiagioFesta commented 5 months ago

FragmentCollector::read_frame() which use async fn parse_frame_header does not remember the read pointer, so if it is canceled in the middle, the data read from tcp stream will be forgotten in next call, because re-enter the read_frame, we start from read from index 0

I am not familiar with websocket wired-protocol, I wondering if this is potential risk

Definitely FragmentCollector::read_frame() is not cancel safe (regardless if automatic pong/close is set or not). If the future is cancelled the framing logic might be interrupted in the middle and, thus, next read will produce a protocol error.