Some of this should have been obvious, but ... In the process of trying to understand some pool stuff, I came to some leftover multicast stuff.
When the pool code gets an IP address, it doesn't setup a peer slot. It just sends a normal client request packet. When the answer returns, the receive routine decides it's a manycast packet and hands it off to handle_manycast() which makes the peer block. The key to that decision is a table lookup in findpeer(). It uses MATCH_ASSOC() to look in AM which is two dimensional. One is the type of packet. The other is the local state that I haven't sorted out yet. There is a hash table on remote IP address to find the peer block. Mumble. It's working now. We can clean things up when I get the rest of the DNS stuff over the hump. I think the right thing to do is make the peer block early on and throw them away if there isn't any response. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
