Tanto UDP como TCP utilizan la abstracción de sockets, que proporciona los puntos extremos de la
comunicación entre procesos. Cada socket se asocia con un protocolo concreto, que puede ser UDP o TCP.

Para los procesos receptores de mensajes, su socket debe estar asociado a un puerto local y a una de las
direcciones Internet del computador donde se ejecuta.

Los procesos siempre tienen que usar un socket para enviar y otro socket para recibir.

Cada computador permite un gran numero (2^16) de puertos posibles, que pueden ser usados por los procesos locales para recibir mensajes.

Esta clase proporciona un constructor que crea una instancia compuesta por una cadena de bytes que almacena sólo los siguientes campos: el mensaje, la longitud del mensaje y la dirección Internet del socket destino.

Esta clase proporciona otro constructor para cuando se recibe un mensaje. Sus argumentos especifican la cadena de bytes en la que alojar el mensaje y la longitud de la misma.

El mensaje recibido puede recuperarse del DatagramPacket mediante el método getAddress.

Todas las respuestas anteriores (A, B, y C) son incorrectas.

Una llamada a procedimiento remoto ocurre cuando un programa cliente llama a un procedimiento de otro programa en ejecución en un proceso servidor.

Los servidores no pueden ser clientes de otros servidores, es decir, no se permite las cadenas de RPC.

El cliente que accede a un servicio incluye un procedimiento de resguardo para cada procedimiento en la
interfaz de servicio. Este procedimiento de resguardo juega un papel similar al de un proxy.

El proceso servidor contiene un distribuidor junto a un procedimiento de resguardo de servidor y un
procedimiento de servicio para cada procedimiento de la interfaz de servicio.

Son homogéneos (hacen funcionar conjuntamente aquellos componentes del sistema distribuido que han sido diseñados con características de interoperabilidad) y síncronos (Las notificaciones se envían síncronamente desde los objetos generadores de eventos a todos los objetos que se hayan suscrito a ellos).

Son heterogéneos (hacen funcionar conjuntamente aquellos componentes del sistema distribuido que no han sido diseñados con características de interoperabilidad) y síncronos (Las notificaciones se envían síncronamente desde los objetos generadores de eventos a todos los objetos que se hayan suscrito a ellos).

Son homogéneos (hacen funcionar conjuntamente aquellos componentes del sistema distribuido que han sido diseñados con características de interoperabilidad) y asíncronos (Las notificaciones se envían asíncronamente desde los objetos generadores de eventos a todos los objetos que se hayan suscrito a ellos).

Son heterogéneos (hacen funcionar conjuntamente aquellos componentes del sistema distribuido que no han sido diseñados con características de interoperabilidad) y asíncronos (Las notificaciones se envían asíncronamente desde los objetos generadores de eventos a todos los objetos que se hayan suscrito a ellos).

En el modelo de objetos de CORBA los clientes no son objetos necesariamente; un cliente podrá ser cualquier programa que envíe mensajes de petición a los objetos remotos y reciba las respuestas.

No se puede implementar un objeto CORBA en un lenguaje que no sea orientado al objeto, sin el concepto de clase.

El concepto de clase no existe en CORBA, por tanto, no se pueden definir clases en CORBA IDL.

En CORBA no se pueden pasar instancias de clases como argumentos.

Extends.

Oneway.

Resolve.

Maybe.

Tanto como cliente como servidor.

Sólo como cliente.

O como cliente o como servidor.

Ninguna respuesta anterior es correcta.

Crea.

Lee.

Escribe.

Elimina.

Todas las implementaciones de NFS soportan el protocolo de NFS: un conjunto de llamadas a procedimientos remotos que proporcionan el medio para que los clientes realicen operaciones en un almacén de archivos remotos.

El protocolo NFS es dependiente del sistema operativo.

Las solicitudes que se refieren a archivos en un sistema de archivos remoto se traducen en el módulo cliente a operaciones del protocolo NFS y después se trasladan al módulo servidor NFS en el computador que mantiene el sistema de archivos relevante.

Los módulos cliente y servidor NFS se comunican utilizando llamadas a procedimientos remotos. El sistema RPC de Sun, se desarrollo para su uso en NFS.

Sólo UDP.

Sólo TCP.

Tanto con TCP como con UDP.

No es compatible con UDP y TCP.

Por medio de una llamada link al servidor.

Por medio de una llamada readlink al servidor.

Por medio de una llamada rmdir al servidor.

Por medio de una llamada getattr al servidor.

Cualquier proceso que necesite acceder a un recurso especifico debe poseer su nombre o un identificador.

Los nombres puros son simplemente patrones de bits sin interpretar. Los nombres no puros contienen información acerca del objeto al que nombran; en particular pueden contener información sobre la ubicación del objeto.

Los nombres puros no necesitan buscarse antes de ser usados.

Las direcciones son eficaces para acceder a los objetos, pero los objetos a veces cambian de localización, por lo que las direcciones no siempre resultan adecuadas como medio de identificación.

El nombre.

El atributo.

La dirección.

el identificador.

Un espacio de nombres es la colección de todos los nombres válidos reconocidos por un servicio particular.

Que un nombre sea válido significa que el servicio intentara su búsqueda, incluso si ese nombre resulta no estar asociado a ningún objeto, es decir, esta desvinculado.

Los espacios de nombres requieren de una definición sintáctica.

La ventaja mas importante de los espacios de nombres planos es que cada parte de un nombre se resuelve con relación a un contexto separado, y puede usarse el mismo nombre en diferentes contextos con diferentes significados.

Sí, siempre.

Sí, si el servidor esté montado siguiendo un espacio de nombres jerárquico.

Sí, si el servidor esté montado siguiendo un espacio de nombres plano.

No, todos los nombres tienen que referirse a la raíz global.

Servicios de búsqueda.

Servicios Jini.

Cliente Jini.

Servicios de resolución.

HTTP es un protocolo de petición-respuesta. El cliente envía un mensaje de petición al servidor que contiene el URL del recurso solicitado.

En la versión 1.0 de HTTP el cliente puede solicitar varios recursos por cada petición HTTP.

Por defecto HTTP restringe a los usuarios el acceso a los recursos publicados.

Los navegadores son siempre capaces de manejar o hacer buen uso de cualquier tipo de contenido.