On Tue, 2009-06-09 at 09:24 +0200, Alan DeKok wrote: > Umm.... no. It means they protocol was designed from an incomplete > problem statement, and an incomplete knowledge of the system. That > isn't good engineering practice.
Maybe - but it's the way a good many, in fact most, of the main protocols we use today have become what they are. People do their best, then the real world comes along and reminds them of all the things they forgot. It's normal for stuff to need fixing. This doesn't mean DHCP failover is a good protocol. There are enough legitimate gripes to throw rocks at. > See earlier messages in this thread. I (a) found a theoretical issue > with the protocol, and (b) demonstrated it in a live system. I missed it. What was it again? > Yes, it doesn't implement the various states that the ISC > protocol uses. However, those states are largely there because of > implementation decisions, rather than theoretical analysis. You do need quite a few states for leases, and you need some mechanism for transitioning between those states in an orderly fashion, in a way that does not invalidating the contract you have with your DHCP clients. But these lease states aren't the same states as those used in the DHCP failover protocol. Seems to me you don't need *any* of those, because the servers simply do not have to communicate directly. They "communicate", if at all, through changing state in a shared database. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
signature.asc
Description: This is a digitally signed message part
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html