I have not read the fix. I was just wondering that this fix save the wait time, but increase the networking traffics, and increase the workload of KDC servers. I think the KDC timeout should be corner cases for TCP, and it is tolerable for UDP connections. I'm not confident that this is a cost-effective update if we considering the overall system of Kerberos.
Xuelei On 6/24/2014 4:17 PM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8014870/webrev.00/ > > In Kerberos, when trying to request for a ticket, we tried multiple KDC > servers for multiple times. Before this fix, we connect to a server, wait for > 30 seconds (the default kdc_timeout). If there is no answer, go to the next > KDC, wait for another 30 seconds, and so on. If none of the KDCs replies. We > do more rounds (max_retries, default 3) of connections, and fail at last. > Altogether with 3 KDCs we will wait at most 3*30*3=270 seconds. > > After this fix, connections are non-blocking and made every second, so they > can wait at the same time. The kdc_timeout default is also reduced to 10 > seconds (the same as other vendors). At the worst case, we will wait > 3*3+10=19 seconds. > > You might say that changing kdc_timeout to 10 seconds matters a lot here but > actually the wait-together style is much more helpful. Suppose only the 3rd > KDC is alive, the old code needs to wait for 60 seconds to be able to connect > to it, while the new one only needs to wait for 2 seconds, and this has > nothing to do with kdc_timeout. > > Because of this, I've thrown away the old krb5.kdc.bad.policy security > property. It's now not worth remembering which KDC is alive and which is not. > > All changes are inside the KdcComm.java file. Others are test and removal of > useless things. > > I've included net-dev@ because these are all NIO calls, which I was no > familiar with. > > Thanks > Max >
