[tracking] net::TcpStream

[dignifiedquire]

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

• connect
• connect_timeout
• local_addr
• nodelay
• peek
• peer_addr
• read_timeout
• set_nodelay
• set_nonblocking - makes no sense in this context probably
• set_read_timeout
• set_ttl
• set_write_timeout
• shutdown
• take_error
• try_clone (I remember some discussion, so might not be happening)
• 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