mozilla/rust — pull request #2751 by olsonjeffery (2012-06-29 14:15:37+00:00)
Title: more work on net::tcp and net::ip (resubmit)

### NOTE: resubmitting against `incoming`. One addition commit to fix 32bit linux issues.

(hopefully) just in time for 0.3!

### What's included

* more work/cleanup on tcp tests. found and fixed a few bugs/memory leaks around failures to bind/connect
* reworked `net::ip` to utilize libuv's facilities for representing IP addresses. As a consequence, we have IPv6 support, now (_update:_ closes #2656)! (see caveat below)
* added `net::ip::get_addr()` that will return an `[ip_addr]/~`, utilizing libuv's `uv_getaddrinfo` call under the hood. We have (albeit simplistic) name resolution!
* I dumped a large chunk of the `net::tcp` API (the server workflow that returned a port-like object to listen on for new connections).. we're still stuck with the callback that runs on the libuv thread .. I was going to add another overload that will just `accept()` every new connection, sidestepping the need for running a blocking callback, but then I took an array to the knee (just kidding.. I ran into a wild CC bug and decided to back out the work). But the code around the tcp server workflow was pretty well refactored that I can add this new workflow with relatively little additional LOCs.
* `impl`s for `io::reader` and `io::writer` that wrap `net::tcp::tcp_socket` in a simple buffer. This is happening as part of a larger conversation/proof-of-concept for revisiting Streams as a generalized concept, in rust.

### What's next?

* We need to rebase the libuv submodule (node.js 0.8.0 just dropped and there's been a lot of change in upstream libuv). This will bring a few API changes that could prove to be pretty useful to us. Hopefully this won't entail too much work on our end.
* I'd love to take a crack at using rust-bindgen to generate the libuv bindings, but there'll all kinds of pitfalls that this entails. I'll probably give it a try, but not hammer on it too hard if I hit a wall.
* There are a few dangling pieces of tcp API i haven't added (like setting the keepalive).
* UDP
* async filesystem stuff that libuv exposes.
* ...?

### caveat about IPv6:

By the admission of libuv's devs, IPv6 support is somewhat spotty, atm. Insofar as a malformed address that is passed in to `uv_ip6_addr/name` will still parse correctly. So users don't have any sanity checks that what they're plugging in will actually work. We're still in a better place than we were, though. The "right answer", in the mid-term, is to roll a pure-rust string parser for IPv6 addresses, like what we already have for IPv4. That way we can be sure we're passing valid input to libuv.

questions/feedback apprecaited, as always.