timeouts over TCP when <n> first nameservers timeout over UDP as
previously the TCP would connect again to the first and only the
first nameserver in task->addrlist.

This would need to be ultimately fixed in TCP Fast Retransmit.

Karel Slaný authored 8 years ago and Ondřej Surý committed 8 years ago

The control structure is part of the resolver context.

Karel Slaný authored 8 years ago and Ondřej Surý committed 8 years ago

Use ENABLE_cookies=yes variable to compile functionality.

Karel Slaný authored 8 years ago and Ondřej Surý committed 8 years ago

Cookies are not stored in separate cache.

Marek Vavrusa authored 8 years ago and Ondřej Surý committed 8 years ago

the TLS sessions now bypass the usuall event loop asynchronous iops
this is because the whole operation is synchronous right now, and
implementing asynchronous send operations would require TLS session to
restart write events on the event loop and making sure the "on complete"
callback is called eventually

the e638f9fb introduced deduplication
for queries over UDP, the idea is to track same queries and answer
only once, however that introduces both constant processing and
memory overhead and could break clients who count packet loss
by queries sent/received. disabling for now.

* in the begin() layer, the incoming query is
  exposed as req->qsource.packet, it is invalidated
  after begin() and should not be modified
* the destination address (local interface) is
  also tracked for filtering purposes

previously the buffer for TCP pkt reassembly was
not correctly cleared and fragmented answers
were rejected 

* when enqueued task terminated earlier than leader
  task because of timeout, it wasn't dequeued from
  the waitlist immediately, but it didn't have any
  outstanding outbound queries. when leader task
  terminated, it removed this task and updated its
  outbound query, which didn't exist. this triggered
  a 16B write in undefined location
* fixed timeout timer being scheduled for closing
  without holding reference to parent task

many clients do frequent retransmits of the query
to avoid network losses and get better service,
but then fail to work properly when a resolver
answers SERVFAIL to some of them because of the
time limit and some of them NOERROR. 
it's also a good idea to avoid wasting time
tracking pending tasks to solve the same thing.

if the upstream TCP query timeouted or the connection
was severed, it would dissociate the handle from
original query, so the query would be solved
but the requestor wouldn't see the answer unless
he requeried