Bulgarian mirror 10 Gbps

PuTTY semi-bug async-dns

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

DNS lookups are synchronous. We could make them async quite easily, which would stop the last potential delay before the PuTTY window appears and would also prevent an absent DNS server from hanging PuTTY while a remote-to-local port forwarding times out on DNS; but ideally I'd like an abstraction of DNS so that we can still port later (since the socket API only has synchronous DNS). Porting to Unix will be fine (we can use adns), as will the Mac OS (where almost everything can be asynchronous), and any thread-capable OS won't have a problem. Everything else will just have to degrade gracefully to synchronous DNS.

SGT, 2003-02-07: I now think I have some idea of how to design a DNS abstraction which can cope equally well with being implemented synchronously or asynchronously. It's rather simple, actually: sk_namelookup acquires a couple of extra parameters, in the form of a function pointer and a context handle to be passed to that function. The code which calls sk_namelookup should expect that function to be called in turn on completion of the DNS lookup. Then a synchronous DNS implementation could actually call the function straight from sk_namelookup itself, whereas an asynchronous one could call it from whatever callback ends up getting hold of the results of the lookup. Client code, of course, will have to be written in such a way that it doesn't mind which happens; in practice that will probably mean the function which called sk_namelookup should terminate immediately after doing so, rather than doing anything which might need to be done before or after the DNS lookup.

Patch (unreviewed): Pine.LNX.4.60.0510092209320.31985@maxwell.compbio.ucsf.edu