Questão de Redes de Computadores — Acesso Remoto (VNC, TeamViewer, RPC, etc.) — VUNESP 2023

RPC: o papel do skeleton (stub do servidor)

Gabarito: letra A. No contexto de RPC (Remote Procedure Call), o skeleton — também chamado de stub do servidor — é o componente que, no lado do servidor, recebe os dados da chamada remota (já deserializados) e os converte em uma chamada de procedimento local, invocando a função real do servidor. Essa é a função descrita na alternativa A, que corresponde exatamente ao papel do skeleton.

A RPC (Remote Procedure Call) é uma técnica que permite que um programa chame um procedimento que executa em outra máquina como se fosse uma chamada local. O objetivo é ocultar os detalhes de comunicação de rede do programador. Para isso, a arquitetura clássica de RPC (proposta por Birrell e Nelson, em 1984) utiliza dois componentes auxiliares: o stub do cliente e o stub do servidor (também chamado de skeleton).

O stub do cliente fica no espaço de endereçamento do cliente e tem o mesmo nome do procedimento remoto. Quando o programa cliente chama esse stub, ele empacota os parâmetros em uma mensagem — processo chamado de marshaling (ou empacotamento) — e envia essa mensagem pela rede ao servidor. Já o skeleton (stub do servidor) fica no lado do servidor: ele recebe a mensagem, desempacota os parâmetros (faz o unmarshaling) e invoca o procedimento local correspondente, passando os parâmetros já convertidos. A resposta segue o caminho inverso: o skeleton empacota o resultado e o envia de volta ao stub do cliente, que o desempacota e o entrega ao programa chamador.

Vamos acompanhar as etapas de uma chamada RPC, conforme descrito na literatura clássica de redes (Tanenbaum):

1. O cliente chama o stub do cliente (chamada local, com parâmetros na pilha).

2. O stub do cliente empacota os parâmetros em uma mensagem (marshaling) e faz uma chamada de sistema para enviá-la.

3. O sistema operacional envia a mensagem pela rede até o servidor.

4. O sistema operacional do servidor entrega a mensagem ao skeleton (stub do servidor).

5. O skeleton desempacota os parâmetros e chama o procedimento servidor real, com os parâmetros já convertidos.

A resposta segue o mesmo caminho no sentido inverso.

A pegadinha desta questão está em confundir o papel do skeleton (lado do servidor) com o do stub do cliente (lado do cliente). O stub do cliente é quem serializa os parâmetros (alternativa C); o skeleton é quem os deserializa e converte em chamada local (alternativa A). A banca explora exatamente essa inversão de papéis.

Alternativa A — ✅ Correta ⟵ GABARITO

O skeleton (stub do servidor) é o componente que, no lado do servidor, recebe a mensagem com os parâmetros da chamada remota, desempacota esses dados (faz o unmarshaling) e os converte em uma chamada de procedimento local, invocando a função real do servidor. É exatamente o que a alternativa descreve: "traduzir dados recebidos da chamada remota, convertendo esses dados em uma chamada de procedimento local no servidor".

Alternativa B — ❌ Incorreta

Abrir uma conexão TCP com o servidor é uma função da camada de transporte/rede, não do skeleton. O skeleton atua acima dessa camada: ele recebe a mensagem já entregue pelo sistema operacional (que cuidou do transporte) e a converte em chamada local. A conexão TCP, quando usada, é estabelecida pelo sistema operacional ou pela infraestrutura de comunicação, não pelo skeleton.

Alternativa C — ❌ Incorreta

Serializar os parâmetros da chamada remota no cliente é função do stub do cliente, não do skeleton. O marshaling (empacotamento) é feito no lado do cliente, antes do envio pela rede. O skeleton, no servidor, faz o processo inverso: desempacota (unmarshaling) os dados recebidos.

Alternativa D — ❌ Incorreta

Fornecer uma lista de servidores ativos é uma função de serviços de diretório ou de balanceamento de carga, não do skeleton. O skeleton é específico de um procedimento remoto: ele representa aquele procedimento no servidor e não tem qualquer papel em descoberta de servidores ou seleção de destino.

Alternativa E — ❌ Incorreta

Oferecer mecanismo de persistência abstrata é uma função de camadas de acesso a dados ou de middleware de persistência (como ORMs), não do skeleton. O skeleton apenas faz a ponte entre a mensagem recebida e a chamada local do procedimento; a persistência, se houver, é responsabilidade do próprio procedimento servidor ou de outras camadas da aplicação.

Gabarito: letra A