[19917] in Kerberos_V5_Development
Re: Logic behind lib/krb5/os/k5_sendto()
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Apr 18 15:03:16 2019
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=
<dilyan.palauzov@aegee.org>,
<krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <ed276b3e-ce80-eb58-6ca7-4c2ccbe39d87@mit.edu>
Date: Thu, 18 Apr 2019 15:02:55 -0400
MIME-Version: 1.0
In-Reply-To: <5920325c9fc52e960c3043831835dd597ee1ab4c.camel@aegee.org>
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On 4/18/19 2:25 PM, Дилян Палаузов wrote:> Does this mean, that the TCP
connection is also retried more than once? You wrote, that there is a
single try to open a
> TCP connection.
Only a single non-blocking TCP socket is opened per KDC, but that socket
remains open for the whole duration, and the kernel will retry the TCP
connection on its own schedule.
> But I think resending the queries in this case to krb5kdc makes think worse, because the krb5kdc will have to deal then
> with even more (repeated) queries, and this slows everything down, when it is already slow, compared to a case, where
> queries are not retried.
Possibly, but the client has no way to distinguish between a UDP packet
getting lost and the KDC being slow to respond.
The KDC does have a lookaside cache which records the responses to
recent requests, so a retransmitted request should be processed with
less effort than processing the original request.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
