Open Rohit171994 opened 2 years ago
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
?
i am not sure weather server would see EAGAIN
, if there is no data to read and still tries to read the socket.
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>()?;
whereread_u16
is frombyteorder::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,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:On other hand if we send as close message using
ping
,then it don't give the above error and is successful on linux . I didn't understand why it behave different on
mac
andlinux
, can anyone please help?