[tracking] net::TcpStream

[dignifiedquire]

When working with TcpStream I realized some things are still missing, this is a list for tracking those

• [x] connect
• [ ] connect_timeout
• [x] local_addr
• [x] nodelay
• [x] peek
• [x] peer_addr
• [ ] read_timeout
• [x] set_nodelay
• [ ] ~~set_nonblocking~~ - makes no sense in this context probably
• [ ] set_read_timeout
• [x] set_ttl
• [ ] set_write_timeout
• [x] shutdown
• [ ] take_error
• [ ] ~~try_clone~~ (I remember some discussion, so might not be happening)
• [x] ttl
• [ ] write_timeout

[tomaka]

Aren't all methods that end with _timeout hacks due to the synchronous nature of these operations in the stdlib? Do we really need to reproduce them in an asynchronous context?

[dignifiedquire]

@tomaka they could still be useful, as convenience methods. Alternatively adding some documentation on how to achieve the same effect with the new tooling might be a better way to go.

[ArtemGr]

Regarding the read calls. Let's say that I've asked to read 7 bytes and the other side has sent me 6 bytes ("foobar").

Will the TcpStream::poll_read immediately return me Ready(Ok(6))? Can I be sure that it won't be Pending until a seventh byte arrives?

And would it make sense to repeat the TcpStream::poll_read with a smaller buffer if invoking it with a larger buffer returns Pending?

Similarly, will an await on the TcpStream::read return the 6 bytes soon as they arrive? Or will it keep waiting for the 7th byte?

This is usually under-specified in, say, the POSIX read calls and hence we have to read byte-by-byte from some streams if we want to access the incoming data as soon as it is available from the network interface. Would be nice to avoid these byte-by-byte reads while using async-std.

[SuperHacker-liuan]

keepalive & set_keepalive is useful when peer suddenly lose its access to network.

[Fishrock123]

keepalive is an HTTP thing, not a tcp thing?

[SuperHacker-liuan]

keepalive is an HTTP thing, not a tcp thing?

FYR, https://tools.ietf.org/html/rfc1122#page-101