No contexto de NETBIOS sobre TCP, quando uma aplicação pede ...

Alternativa correta: A - stack

Para compreender essa questão, precisamos revisitar alguns conceitos importantes sobre a arquitetura TCP/IP e como o NetBIOS opera sobre essa arquitetura.

NetBIOS (Network Basic Input/Output System) é uma API que permite a comunicação entre computadores em uma rede local. Ele opera na camada de Sessão do modelo OSI, mas quando estamos falando de NetBIOS sobre TCP/IP (NBT), ele se baseia nas camadas de transporte e rede do modelo TCP/IP.

Quando uma aplicação quer se comunicar com outra aplicação remota usando NetBIOS sobre TCP, ela precisa resolver o nome NetBIOS para um endereço IP. Este processo é conhecido como resolução de nome NetBIOS. A aplicação envia um pacote de "lookup" ao servidor de nome NetBIOS (WINS - Windows Internet Name Service, por exemplo) para obter o endereço IP correspondente ao nome NetBIOS da aplicação remota.

A questão foca em quem é responsável por enviar esse pacote de "lookup". A resposta correta é que essa tarefa cabe à "stack" (pilha) de protocolos TCP/IP. Em outras palavras, a pilha de protocolos TCP/IP é responsável por implementar a funcionalidade necessária para enviar e receber pacotes de dados, incluindo pacotes de resolução de nome NetBIOS.

Vamos analisar as alternativas incorretas para entender por que elas não são adequadas:

• B-Node: É um modo de operação do NetBIOS que usa broadcast para a resolução de nomes. Embora envolva resolução de nomes, não é responsável por enviar pacotes de lookup na camada de rede inferior.
• H-Node: É outro modo de operação do NetBIOS que combina broadcast e consultas a servidores WINS. Novamente, não é responsável pela tarefa específica de enviar pacotes de lookup na camada de rede.
• Broadcast: Refere-se a um método de comunicação onde uma mensagem é enviada para todos os nós na rede. Não se refere a quem envia o pacote de lookup.
• Roll call: Não é um termo relevante no contexto de NetBIOS ou TCP/IP, tornando-se incorreto para a questão.

Assim, a pilha de protocolos TCP/IP é a responsável por gerenciar a comunicação e a transmissão dos pacotes de dados necessários para estabelecer uma conexão TCP, incluindo a resolução de nomes NetBIOS. Portanto, a alternativa A é a correta.

Caso tenha mais dúvidas ou precise de mais explicações sobre o tema, estou à disposição para ajudar!

Quando uma aplicação NetBIOS pretende comunicar com um correspondente remoto particular, fornece o nome para a sua própria camada e pede para efectuar a necessária ligação. O stack realiza a ligação comunicando com o stack de nível idêntico na maquina remota. De modo a obter a maquina certa, dado unicamente um nome, o stack tem de ter uma maneira de associar o nome com o endereço da estação destino. Conceptualmente o stack tem de recorrer a uma base de dados de nomes, uma construção onde os mapeamentos entre nomes e endereços são mantidos.

A especificação do NetBIOS, sem se referir a tal estrutura, presume a sua existência. E define varias propriedades de nomeação que dizem como a base de dados deve ser usada.Antes que uma aplicação possa comunicar na rede, o seu nome tem de ser "conhecido" na rede. De modo a que o seu nome seja conhecido, a aplicação faz uma chamada a API e instrui-a de modo a adicionar o nome á rede. Conceptualmente, esta operação cria uma afiliação entre um nome de uma aplicação e o do próprio stack na rede. Ambos os nomes "group" e "unique" são definidos pela API NetBIOS. Quando um nome único é adicionado o stack tem expectavelmente de garantir que o nome é realmente único ( i. e. Que o nome não está a ser usado em mais nenhuma estação na rede ). Quando é adicionado um nome de um grupo, é expectável assegurar que qualquer outra estação que use o mesmo nome o use como identificador de grupo. Quando uma aplicação termina as comunicações na rede, o stack é instruído para remover o nome da rede, terminado a afiliação estabelecida anteriormente com o endereço da estação e tornando o nome desconhecido na rede.

B-Node - Tipo de consulta que usa broadcast

P-None - Tipo de consulta que usa um servidor WINS

M-Node - Tipo de consulta que realiza primeiro um B-Node e em caso de falha executa uma consulta do tipo P-None

H-Node - Tipo de consulta que realiza primeiro um P-None e em caso de falha executa uma consulta do tipo LMHOSTS em casa de falha tenta ainda uma consulta do tipo B-Node