Detect TCP disconnect without reading or writing anything to that socket?

[masnagam]

Version

• tokio: v0.2.11
  • tokio::net::tcp::TcpStream

Description

In #483, it was discussed to use poll_read_ready(Ready::empty()) for detecting TCP disconnect.

After that, poll_read_ready() was removed at 6d8cc4e according to a discussion on gitter as described in #1392 (comment).

Is there any alternative way to detect TCP disconnect without writing or reading anything to/from that socket?

I haven't tried yet, but we might be able to use peek() or poll_peek() for this purpose.

Background

In some situations, it's necessary to detect TCP disconnect without reading or writing anything to/from that socket.

For example, suppose an HTTP server that performs a time-consuming task for a response. This HTTP server don't like to read data from the TCP socket for detecting disconnect in order to support HTTP keep-alive and request pipelining easily. This HTTP server has no data to write until the task outputs something.

If there is no way to detect TCP disconnect other than reading/writing, this HTTP server cannot detect TCP disconnect until the task outputs something.

The similar situation occurs in actix-web. And it seems to leak TCP sockets if clients disconnect while it waits for data from a Stream object:
https://github.com/masnagam/rust-case-studies/tree/master/actix-web-streaming-and-tcp-disconnect

Related Issues

• Provide a way to listen for tcp disconnects #29
• How do I wait for closure of a tokio::net::TcpStream? #483
• tokio_tcp::TcpStream::poll_read_ready fails to detect HUP #1182

Example of detecting TCP disconnect using poll_read_ready()

• vi/websocat@d7b0db2

[masnagam]

Probably, the simplest solution is to restore poll_read_ready(). However, in the historical point of view, this solution may be unacceptable in this project.

Personally, I think it's great for library users that Tokio provides lower level API as already mentioned in #1392 (comment).

[Darksonn]

I think restoring poll_read_ready() would be fine.

[carllerche]

cc @seanmonstar

[carllerche]

This is now tracked by #2968