Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
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): [email protected]