Uma vantagem da pesquisa é que ela limita o dano que pode ser causado se uma mensagem desaparecer ou se o estado de algo for danificado. Se X solicitar seu estado a Y uma vez a cada cinco segundos, a perda de uma solicitação ou resposta resultará apenas na informação de X sendo dez segundos desatualizada em vez de 5. Se Y for reiniciado, X poderá descobrir sobre isso na próxima o tempo Y é capaz de responder a uma das mensagens de X. Se o X for reiniciado, talvez nunca mais lhe peça nada, mas quem estiver observando o status do X deve reconhecer que foi reiniciado.
Se, em vez de X pesquisar Y, X confiasse em Y para informá-lo sempre que seu estado fosse alterado, se o estado de Y mudasse e ele enviasse uma mensagem para X, mas por qualquer motivo, essa mensagem não foi recebida, X poderá nunca tomar conhecimento da alteração . Da mesma forma, se Y for reiniciado e nunca tiver qualquer motivo para enviar uma mensagem a X sobre algo.
Em alguns casos, pode ser útil para o X solicitar que Y envie autonomamente mensagens com seu status, periodicamente ou quando elas forem alteradas, e só faça a pesquisa X se demorar demais sem ouvir nada de Y. Esse design pode eliminar o é necessário que X envie a maioria de suas mensagens (normalmente, X deve ao menos ocasionalmente informar Y de que ainda está interessado em receber mensagens e Y deve parar de enviar mensagens se demorar demais sem qualquer indicação de interesse). Tal projeto exigiria, no entanto, que Y persistissemantenha as informações sobre o X, em vez de poder simplesmente enviar uma resposta para quem as pesquisou e depois esquecer imediatamente quem era. Se Y for um sistema incorporado, essa simplificação pode ajudar a reduzir os requisitos de memória o suficiente para permitir o uso de um controlador menor e mais barato.
A pesquisa pode ter uma vantagem adicional ao usar um meio de comunicação potencialmente não confiável (por exemplo, UDP ou rádio): ele elimina amplamente a necessidade de reconhecimento da camada de link. Se X enviar a Y uma solicitação de status Q, Y responder com um relatório de status R e X ouvir R, X não precisará ouvir nenhum tipo de reconhecimento da camada de link para que Q saiba que foi recebido. Por outro lado, uma vez que Y envia R, ele não precisa saber ou se importar se X o recebeu. Se X envia uma solicitação de status e não obtém resposta, ele pode enviar outra. Se Y enviar um relatório e X não o ouvir, X enviará outra solicitação. Se cada solicitação sair uma vez e fornecer uma resposta ou não, nenhuma das partes precisará saber ou se importar se alguma mensagem específica foi recebida. Como o envio de uma confirmação pode consumir quase a mesma largura de banda que uma solicitação ou relatório de status, o uso de uma viagem de ida e volta de relatório de solicitação não custa muito mais do que custaria um relatório e uma confirmação não solicitados. Se o X enviar algumas solicitações sem obter respostas, em algumas redes roteadas dinamicamente, será necessário habilitar as confirmações no nível do link (e solicitar na solicitação que Y faça o mesmo) para que a pilha de protocolos subjacente possa reconhecer o problema de entrega e procurar por uma nova rota, mas quando as coisas estiverem funcionando, um modelo de relatório de solicitação será mais eficiente do que usar confirmações no nível do link.