TcpStream behaviour and shutdown. #5968
-
I am writing an application that uses TcpStream to read some data off a tcp socket and process it. The program writing data is in C++ and i cannot change that. in case the Do I need to manually shutdown the TcpStream or can i just create a new one and bind it to the existing variable? Will the underlying socket of the first TcpStream be dropped when the object gets overwritten by the new function call to connect? If I need a manual shutdown of the socket, why is that API available only on the AsyncWriteExt trait, when the std::net::TcpStream exposes it for the class as a whole? Also, in case I keep calling read_buf on a TcpStream that returned 0, what will the code do? Could I incur allocation penalties since i would basically be calling into read_buf very often due to the buffer not having data and thus skipping all the data processing parts and going at the beginning of the loop again? Basically in pseudocode (please ignore the missing async keywords and poor error handling, but look at comment at the bottom):
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
When you write:
This will do the following operations:
Running the destructor is enough to close the socket.
The The You don't have to call |
Beta Was this translation helpful? Give feedback.
When you write:
This will do the following operations:
connect()
.stream
.connect()
into thestream
variable.Running the destructor is enough to close the socket.
The
read_buf
method only returns 0 if the read direction of yourTcpStream
has been closed. Once that happens, you will never get any more data, so all future calls toread_buf
will also return 0. You should stop trying to read from it when you get a read of length zero.The
AsyncWriteExt::shutdown
method doesn't do the same thing as dr…