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

Close message different behaviour on Mac and Linux. #270

Open
Rohit171994 opened this issue Sep 2, 2022 · 2 comments
Open

Close message different behaviour on Mac and Linux. #270

Rohit171994 opened this issue Sep 2, 2022 · 2 comments

Comments

@Rohit171994
Copy link

i am implementing multi-threaded websocket client server chat application. On client side i am using rust-websocket library, while on the server side i am not using this library rather manually reading from the socket(TcpStream) connection.

On server side i am trying to read the data as let buf = socket.read_u16::<BigEndian>()?;
where read_u16 is from byteorder::io::ReadBytesExt.
it work fine for the text message sent by the client,
The issue starts when we try to close any client by sending close message to the server as below,

let close_msg = Message::close();
let res = sender.send_message(&close_msg);

while reading this message on server side, with let buf = socket.read_u16::<BigEndian>()?; , it is successful on mac, but while in Linux it fails with wouldblock error i.e:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }

On other hand if we send as close message using ping,

let close_msg = Message::ping(vec![1u8]);;
let res = sender.send_message(&close_msg);

then it don't give the above error and is successful on linux .
I didn't understand why it behave different on mac and linux , can anyone please help?

@vi
Copy link
Member

vi commented Sep 2, 2022

Do I understand correctly that type of message sent by client affects whether server would see EAGAIN?

If so, network traffic dump, e.g. tcpdump -w file.cap is probably needed to compare incoming TCP packets in both cases. Capturing strace output, e.g. strace -fto log.txt my_server may also be helpful.


It is strange though that Tokio is "afraid" of EAGAIN. I don't think it should panic even if some bad client deliberately tries to send malformed data. Does trying some previous version of Tokio/mio change anything? Or does the Result unwrap happen in your code, not Tokio code? Maybe retry with RUST_BACKLOG=1?

@Rohit171994
Copy link
Author

i am not sure weather server would see EAGAIN, if there is no data to read and still tries to read the socket.

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

No branches or pull requests

2 participants