Speaking of consequences, seems the server change had bigger consequences than originally planned. SVN is still down (on the bright side - it was up for four hours yesterday!) and mail still doesn't work (so if you'v mailed me during last few days, I haven't received it).

Since SVN access is down, here are new builds for Windows, Linux, as well as source code snapshot.

Most it's been bugfixing after the optimization cycle, things seem to be back under control (except for an issue with upload slots - too many of them). I also did some cleanup in hnbase module, networking subsystem - removed lazy disconnection functionality (it allowed marking a socket for disconnection after all pending data has been sent out), and removed connect by hostname functionality (allowed doing socket->connect("www.google.com", 8) -like calls). The reasoning for the removal of those two is simple - they are error-prone, their usability questionable, and near-impossible for the API to do the right thing under all usage scenarios.

For the lazy disconnections, what if data is received when the socket is marked for disconnection? The client code would want to handle the data most likely, but that would result in a disconnection at some random time. If you want a delayed disconnection, use socket timeouts instead - that's what they are for.

As for the DNS resolution integration within the networking API, it just can't do the right thing in case a name resolves to multiple IP addresses. What should the API do? Connect to the first found IP, but what if that fails? Connect to next one? What about timeouts? These decisions should not be made by an API transparently, these should be made by client code, which makes the integration pointless, and even harmful. There's a good and working API for dns resolution, use it - that's what it's for.

Madcat, ZzZz