websockets-rs / rust-websocket

A WebSocket (RFC6455) library written in Rust

Home Page:http://websockets-rs.github.io/rust-websocket/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Close message different behaviour on Mac and Linux.

Rohit171994 opened this issue · comments

commented

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?

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?

commented

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