Some really small stuff:

• I can't convert an existing UtpSocket into a UtpStream (no suitable constructor).
• If I bind to 0.0.0.0:0, the underlying UdpSocket will choose a random port. I have no way of retrieving that random port allocation from UtpSocket nor UtpListener currently.
• UtpListener::accept() doesn't return a (UtpSocket, SocketAddr) like TcpListener does.

Thanks, Niall

This line: https://github.com/meqif/rust-utp/blob/88a3aa6410f52eac1a228790c4297b650c1d3274/src/socket.rs#L506

More info: https://github.com/maidsafe/crust/issues/372

We've ran into 'arithmetic operation overflowed' from rust-utp before (just needed to let it execute longe enough), but the new rendezvous code we added started to show the problem much more frequently.

Currently, all reads from the underlying UDP are blocking. This raises several problems, such as:

• no timeout detection on ACKs for sent packets (which need to be resent),
• no timeout detection on receive (which may signal a dead connection),
• no timeout detection on close (meaning a socket may hang in the SocketState::FinSent state indefinitely).

This branch pull request creates a sub-crate with a new trait, WithReadTimeout, implemented for UdpSocket, adding the method recv_timeout(&mut [u8], i64) to it. This method is only properly implemented for POSIX targets, with the Windows implementation being a dummy which ignores the timeout.

Hi Ricardo, this isn't really an "issue", just a question we have so feel free to close it. But, is there a plan to switch rust-utp to mio? I assume it would be a lot of rewrite, both, internally and also to the external API. Or do you think it would make more sense to start from scratch with a new library?

The fixed error is:

src\with_read_timeout.rs:40:13: 40:19 error: unresolved import `select::fd_set`. Maybe a missing `extern crate select`? [E0432]
src\with_read_timeout.rs:40         use select::fd_set;
                                        ^~~~~~
src\with_read_timeout.rs:40:13: 40:19 help: run `rustc --explain E0432` to see a detailed explanation
error: aborting due to previous error

Introduced in commit dfd91141a0c864bd939d9e0f9cd2ff578aeea2f8

Hint taken from https://github.com/maidsafe/rust-utp/commit/c7a7190b53488cc1f132bc55a6686c3990370409#diff-b4aea3e418ccdb71239b96952d9cddb6R81

We're trying to use rust-utp in https://github.com/maidsafe/crust but we have the problem that we need to send data whilst also concurrently waiting for new data to arrive. The obvious fix is a mutex per UtpSocket which is unlocked while udpsocket.recv_from() to allow sends and other operations to run.

If you're not able to do it yourself promptly, would you be interested in a pull request, or is there a better way than the above?

Thanks, Niall

Now that the UDP socket in the standard Rust library reacquired the timeout functions, the old and buggy custom socket timeout implementation can be removed.

Fixes #19. Waiting on Rust 1.4.

Improve code examples in README and module documentation.

The improvements require result_expect (rust-lang/rust#27277), which is available on Rust 1.4 onwards. Merge only when 1.4 is released as stable.

Hi there!

I'm trying out a project which requires uTP, and I came across your crate - which seems quite complete.

I've updated the code to match Rust 2018 edition, and I thought you could want contributions to update the lib.

cheers!

This PR forces the PacketHeader representation to be #[repr(C)]. This fixes an issue where the compiler might reorder the struct's fields, which would mess up the unsafe cast to an array of bytes.

Currently waiting for the new Rust 15.0 beta to be released and tested against master.

Fixes #29

Also adds a passing test test_data_exchange_tcp for comparison.

The uTP test sometimes passes so needs to be run in a loop to make sure it is reproduced. When it passes, it sometimes does so quickly, but it often it takes ~10 seconds to finish.

When it fails, it looks something like this:

test socket::test::test_data_exchange_utp ... thread '<unnamed>' panicked at 'Error { repr: Custom(Custom { kind: TimedOut, error: StringError("Connection timed out") }) }', src/socket.rs:2531
stack backtrace:
   1:     0x7fea7da65540 - sys::backtrace::tracing::imp::write::h5839347184a363c1Tnt
   2:     0x7fea7da67b45 - panicking::log_panic::_<closure>::closure.39955
   3:     0x7fea7da67591 - panicking::log_panic::hcde6d42710304abbWnx
   4:     0x7fea7da56da3 - sys_common::unwind::begin_unwind_inner::h4039843fef6bffefYgs
   5:     0x7fea7da57418 - sys_common::unwind::begin_unwind_fmt::hbbea9d3fc97574084fs
   6:     0x7fea7d9fe3e5 - socket::test::test_data_exchange_utp::_<closure>::closure.19345
                        at /home/peter/work/rust/rust-utp/<std macros>:8
   7:     0x7fea7d9fd61c - std::thread::_<impl>::spawn::_<closure>::_<closure>::closure.19340
                        at ../src/libstd/thread/mod.rs:271
   8:     0x7fea7d9fd5d9 - sys_common::unwind::try::try_fn::try_fn::h1429149916602116162
                        at ../src/libstd/sys/common/unwind/mod.rs:156
   9:     0x7fea7da64a78 - __rust_try
  10:     0x7fea7da611eb - sys_common::unwind::try::inner_try::h81e998e565f2181dwds
  11:     0x7fea7d9fd586 - sys_common::unwind::try::try::h5500681879419574301
                        at ../src/libstd/sys/common/unwind/mod.rs:126
  12:     0x7fea7d9fd3fd - std::thread::_<impl>::spawn::_<closure>::closure.19337
                        at ../src/libstd/thread/mod.rs:271
  13:     0x7fea7d9fe79c - boxed::_<impl>::call_box::call_box::h6452290943018104200
                        at ../src/liballoc/boxed.rs:521
  14:     0x7fea7da66633 - sys::thread::_<impl>::new::thread_start::h0be42f811434f5398Fw
  15:     0x7fea7ca066a9 - start_thread
  16:     0x7fea7d22feec - clone
  17:                0x0 - <unknown>
thread 'socket::test::test_data_exchange_utp' panicked at 'assertion failed: client_t.join().is_ok()', src/socket.rs:2542
stack backtrace:
   1:     0x7fea7da65540 - sys::backtrace::tracing::imp::write::h5839347184a363c1Tnt
   2:     0x7fea7da67b45 - panicking::log_panic::_<closure>::closure.39955
   3:     0x7fea7da67591 - panicking::log_panic::hcde6d42710304abbWnx
   4:     0x7fea7da56da3 - sys_common::unwind::begin_unwind_inner::h4039843fef6bffefYgs
   5:     0x7fea7d9441c7 - sys_common::unwind::begin_unwind::begin_unwind::h7653023640623241003
                        at ../src/libstd/sys/common/unwind/mod.rs:224
   6:     0x7fea7d9fc6e7 - socket::test::test_data_exchange_utp::h1d6c8c8760628933ibj
                        at /home/peter/work/rust/rust-utp/<std macros>:3
   7:     0x7fea7da3a2a6 - boxed::_<impl>::call_box::call_box::h575065112849089642
   8:     0x7fea7da3cc7f - sys_common::unwind::try::try_fn::try_fn::h2198980327506938284
   9:     0x7fea7da64a78 - __rust_try
  10:     0x7fea7da611eb - sys_common::unwind::try::inner_try::h81e998e565f2181dwds
  11:     0x7fea7da3d010 - boxed::_<impl>::call_box::call_box::h15791639090073025805
  12:     0x7fea7da66633 - sys::thread::_<impl>::new::thread_start::h0be42f811434f5398Fw
  13:     0x7fea7ca066a9 - start_thread
  14:     0x7fea7d22feec - clone
  15:                0x0 - <unknown>

I'm using Ubuntu 15.04 and rustc 1.6.0-nightly (1a2eaffb6 2015-10-31).

On Windows, the recv_from operation on the UDP socket may return the following errors, which are expected and should be ignored:

• 10054 (WSAECONNRESET): Windows can send this error if a previous send operation resulted in an ICMP Port Unreachable. And if it's a loopback interface, it can know whether there is already another end to communicate.
• 10040 (WSAEMSGSIZE): This error was randomly appearing in a test that I conducted. Not really sure why it's happening. The frequency decreased when I increased the receive buffer size, but it was not important to get a network up and running.

Without these changes, it was impossible to get a relatively large network running without issues. By large I mean a test that might be too bursting for a single machine to run.

More references:

• http://stackoverflow.com/questions/30749423/is-winsock-error-10054-wsaeconnreset-normal-with-udp-to-from-localhost#comment49588739_30749423
• https://github.com/maidsafe/crust/pull/454

This commit adds a set_read_timeout function similar to Rust's set_read_timeout[1]. The differences compared to upstream are:

• Operation always succeed.
• It takes an i64 instead Duration.

[1] https://doc.rust-lang.org/nightly/std/net/struct.UdpSocket.html#method.set_read_timeout

Your earlier code doesn't retry a socket read receiving EINTR, plus I need connections to die if they are not live. I therefore added a loop of all reads with CONNECTION_TIMEOUT which is 20 secs, as it is for TCP on Linux.

I am calling close() on a CloneableSocket but it does not appear to cause reads in the other side CloneableSocket to exit with an Err. This is because CloneableSocket's recv() is missing the same closed connection detection logic as UtpSocket's recv_form().

The other thing we need is to detect ungraceful connection close. Either a heartbeat, or a timeout since last packet received would work.

Currently rust-utp doesn't allow concurrent reads and writes to the same socket. This limits its usefulness in a production context.

Ways to achieve concurrency

1. Synchronize socket state access/modification and allow cloning,
2. Split UtpSocket into reading and writing halves, and return those instead of a unified socket,
3. Spawn a thread inside UtpSocket or UtpStream to wait for incoming packets on the underlying UDP socket.