Closed GlenDC closed 2 years ago
Hey there,
From running the server example by using RUST_LOG=debug cargo run --example server -- --listen-addr 127.0.0.1:1337 password -u admin -p password
I do get the right amount of bytes transferred as mentioned from the logs:
[2022-05-07T04:03:39Z INFO fast_socks5::server] transfer closed (79, 552)
An improvement we could bring, would be to have to server::transfer()
function to return the amount of bytes transferred: https://github.com/dizda/fast-socks5/blob/f711ae0f26332975ab06fd89c818f622328038a2/src/server.rs#L643
Yes that would be one step in the right direction. Even though it will need to bubble up.
A related problem though is that tokio::io::copy_bidirectional(&mut inbound, &mut outbound).await
doesn't return those values in case of an error, which on MacOS is possible due to the client closing (see #23).
Going to close this one as the other work already contributed by me in combination with the root cause of #23 are the reasons why we do not always receive it. Trying to track it from within this crate wouldn't resolve it or even work due to the issues causing it.
Closing this as such.
In regards to #15. I managed to make that all work. However, and please check the code linked there, I had to make it catch ErroKind (NotConnected/ConnectionReset).
This essentially does mean that we do have access to the bytes send/received (written/read). However even when no error that number does always seem to be (0,0) (used as a router, but even when running a regular server as per your example).
I tried to write copy directional myself (copying the code and catching the error):
However this still has the same issue, that is, the returned data read/written is (0,0).
It is not as simple as that:
From the logs we can see that the size is returned for the initial part of the socks5 stream (header), but once we do the actual transfer we seem to log nothing.
What am I doing wrong here? both in my fork and vanilla code. I really need for my purposes to be able to log the payload size.