Lines Matching full:probes
710 // The addition of "interval / 2" is to make sure that, in the event that any of the probes are
721 // To allow us to aggregate probes when a group of services are registered together,
765 // After three probes one second apart with no answer, we conclude the client is now sleeping
2992 // 2. Scan our authoritative RR list to see what probes we might need to send
3076 // 3. Now we know which queries and probes we're sending,
4477 // then send our responses, probes, and questions.
4479 // We send queries next, because there might be final-stage probes that complete their probing here, causing
4498 LogMsg("mDNS_Execute: SendQueries didn't send all its probes (%d - %d = %d) will try again in one second",
5621 // If we lost the tie-break for simultaneous probes, we don't immediately give up, because we might be seeing stale packets on the network.
5623 // If there really is another live host out there with the same name, it will answer our probes and we'll then rename.
5819 // unicast answer back to the source, because timeliness in answering probes is important.
9503 // to start to break down (e.g. we don't answer probes fast enough, and get name conflicts).
10177 // didn't answer our three probes within three seconds then we'd announce and cause it an unnecessary address conflict.
10199 // Process ARP Requests and Probes (but not Announcements), and generate an ARP Reply if necessary.
10229 // (Strictly speaking we're only checking Announcement/Request/Reply packets, since ARP Probes have zero Sender IP address,
