let's say I have a mut stream which is TcpStream, how could I know that the other side is closed? I have tried if let Err(_) = stream.write(..), but it doesn't seems to work

Generally when a TCP stream is shut down normally, each side will call shutdown(Shutdown::Write) on their end of the stream. When you perform such a shut-down, the other side will see this as a call to read that returns 0 bytes. The tcp stream is fully shut down once both sides have sent such a sign…

so that means I need to set up write or read deadline manually to know if the connection is closed, is there anyway to know it immediately? thank you

What do you mean? The call to read will return immediately when it is closed.

The issue, in my experience, is that one can open a TCP/IP connection between machines and as long as one is exchanging data regularly it is soon noticed if one end or other closes the connection or fails somehow. BUT, when a connection is open with no traffic flowing, one can yank out the ethernet…

The Ethernet standard specifies that the network card shall raise a LINK_STATUS_CHANGE event when the cable is unplugged or plugged in. Unfortunately, most operating systems ignore this event. TCP deals with this fact by having a hard-wired timeout. Since the TCP standard doesn't specify a timeou…

[image] alanhkarp: The Ethernet standard specifies that the network card shall raise a LINK_STATUS_CHANGE event when the cable is unplugged or plugged in. This brings back memories. What happens when the disconnect is not on your local ethernet cable? Far away behind some switches, routers or…

[image] ZiCog: What happens when the disconnect is not on your local ethernet cable? Far away behind some switches, routers or a wireless signal blockage? There are actually two timeouts. In the system I'm using today, the machine responds in about 4-5 seconds when the cable is unplugged. I…

[image] alanhkarp: Liveness in asynchronous distributed systems is an unsolved problem. In fact, Fisher, Lynch, and Patterson proved that the failure of a single node can prevent reaching consensus. Fortunately, the heuristics we use work well enough. Hmm... I thought Leslie Lamport showed t…

[image] ZiCog: I thought Leslie Lamport showed that a distributed system of four nodes could tolerate one Byzantine faulty node/link: https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf That's a protocol error, not a potentially dead node. The problem is that without a reliable failur…

There's some related discussion of checking for closed TCP streams in Rust here: [image] How to detect TCP close? Hi, I'd like to detect TCP client close in server side. I carefully looked at the document: std::net - Rust and try to write some codes. But I couldn't det…

[image] alanhkarp: That's a protocol error, not a potentially dead node. I appreciate that it's time to wind this up. So my last comment here is: That is not the way I read the Byzantine General's paper. It specifically talks of dead/deceptive nodes. And how they are equivalent to dead/decep…

How to know a TcpStream is closed in the other side?

help

mbrubeck December 17, 2020, 7:02pm 12

There's some related discussion of checking for closed TCP streams in Rust here:

Topic		Replies	Views
Why does TcpStream recognizes client dropped connection when reading but not when writing help	3	364	September 18, 2023
How to know when std::net::TcpStream ends help	2	438	November 16, 2022
How to detect TCP close?	12	8379	November 1, 2020
In nodejs I can detect close event for a socket but not in Rust help	9	512	August 3, 2025
TcpStream `write` silently loses one message help	5	1945	February 17, 2020

How to know a TcpStream is closed in the other side?

Related topics