[Bug]: Read returns io.ErrShortBuffer on closed connection about gnet HOT 7 CLOSED

I can apply a workaround, but certainly, preemptively checking the connection status before each read would not be the most efficient or elegant solution.

from gnet.

Honestly, I'm quite surprised that huge corporations are using the code with such behavior in production. Thank you for the code, anyway.

from gnet.

I fail to see what is bothering you. What's your problem with io.ErrShortBuffer?

from gnet.

io.ErrShortBuffer indicates at the same time:

1. there is a short buffer
2. there is not enough data
3. there is a closed connection
   For example, if there is not enough data, the read operation should be repeated after a while to get a new portion. However, there is no reason to do that in case of a closed connection.
   Am I wrong?
   I may have missed an example of how to do it correctly.

We expect to get 3 bytes.

1. conn.Read returns io.ErrShortBuffer because there is no data at all
2. do conn.Read one more time, the client sends 1 byte, and we have io.ErrShortBuffer again
3. the connection took too long, we close the connection in a separate goroutine
4. conn.Read returns io.ErrShortBuffer again

Do you think the behavior is correct? If so, I'll close the report. 🤷‍♂️

from gnet.

I understand that we can track the status with the event handler, or even write the custom state machine.

But my question is about conn.Read behavior.

from gnet.

gnet is a event-driven framework, you should only read data in OnTraffic, why would you call Read() constantly to check if there is data coming? I don't think you're using gnet in the right way.

from gnet.

Thank you for your quick feedback. I appreciate your guidance and will verify the usage to align with best practices.

Maybe I didn't get the idea.

from gnet.