On 16/07/2015 22:41, Shane Kerr wrote:
I think it is worse than flooding with UDP. It allows "fire and forget"
actions from clients:
# we can comfortably fit 20 queries into a single 1280-byte packet
for i = 1 to 20:
packet.append(EXPENSIVE_QUERY)
conn = socket.connect_tcp("someserver", port=53)
conn.write(packet)
# the process can quit and the queries still go...
exit(0)
That shoudn't be possible - as soon as the client side exits the socket
will get closed and any subsequent writes from the server side will
generate an error. AIUI, some IP stacks will even flush the read buffer
if they detect a fully closed socket?
If you have (for example) a maximum of 5 queries per client, then as
soon as one finishes you'll start another one. All from a 7-packet
exchange on the client side, versus a 40-packet exchange with UDP.
(See, TCP can be more efficient!!!)
The goal of this could be load on the resolver, load on upstream
authoritative servers, or something more creative....
I don't think that works (per above)
True.
It's not clear to me whether out-of-order processing makes pipelining
better or worse, actually.
But perhaps a document about TCP in DNS might want to mention this
issue?
Perhaps. I do see out-of-order processing as a somewhat larger issue
than pipelining, though, simply because the possibility exists that some
clients will assume that the packets come back in request order, and
fail to check the QID.
I don't even think there is a race-free way to flush the incoming TCP
read buffer
That might explain why it's not done ;-)
Ray
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
