The `Arc<string>` lived as long as the server in all cases, but this way we
don't have to pay any cache invalidation/coherence costs associated with
constantly incrementing and decrementing the atomic reference count.
If we're just idle waiting for bytes to become available to read and the
connection is forcibly reset or aborted, just treat it as if it were closed
normally. This lets us bubble back the actual number of bytes transmitted.
We are still treating these as errors if we encounter them while actively trying
to write to the host/client.
Should resolve https://github.com/mqudsi/tcpproxy/issues/3
Previously we were only sending an abort signal on successful completion of one
half of a proxied connection and relying on errors to also affect the other
half.
Now we explicitly send an abort after completing with one half of a connection
regardless of whether we did that successfully or with an error.
Previously, if the client closed after receiving a reply, a keepalive connection
to the server would stick around until the timeout, even though we will never
reuse it.
The local port is now optional, in which case a random free port will be used
(and reported in the output). The `--host` argument is now `--remote-host`.
This was insanely hard not due to anything other than lack of
familiarity with futures-rs. It's unfortunate that so much of being able
to use it correctly requires knowledge of futures-rs and not rust
itself. e.g. it is not possible to implement this solution with pattern
matching, usage of futures::future::result() is instead required.
See https://github.com/alexcrichton/futures-rs/issues/551