Please enable JavaScript.

Coggle requires JavaScript to display documents.

RPCs, Glosario - Coggle Diagram

- - - - El cliente envía una petición y se queda a la espera un tiempo determinado.
      - Si no llega la respuesta dentro del tiempo de espera, continúa su ejecución.
      - El cliente no tiene realimentación en caso de fallo (no sabe que pasó).
      - Sólo admisible en aplicaciones donde se tolere la pérdida de peticiones y la recepción de respuestas con retraso (fuera de orden).
  - - - El cliente envía una petición y queda a la espera un tiempo.
      - Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.
      - El servidor no filtra peticiones duplicadas (el procedimiento remoto puede ejecutarse repetidas veces).
      - El cliente puede recibir varias respuestas.
      - Sólo es aplicable cuando se usan exclusivamente operaciones idempotentes (repetibles). Nota: una operación es idempotente si se puede ejecutar varias veces resultando el mismo efecto que si se hubiera ejecutado sólo una. En ocasiones una operación no idempotente puede implementarse como una secuencia de operaciones idempotentes. Admisible en aplicaciones donde se tolere que se puedan repetir invocaciones sin afectar a su funcionamiento.
  - - - El cliente envía la petición y queda a la espera un tiempo.
      - Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.
      - El servidor filtra las peticiones duplicadas y guarda historial con las respuestas enviadas (servidor con memoria). El procedimiento remoto sólo se ejecuta una vez.
      - El cliente sólo recibe una respuesta si la petición llegó y se ejecutó el procedimiento, si no recibe informe del error.
- - - - Causas físicas: accidentes, caída de un rack, o incendio o inundación
      - Fallos en el suministro eléctrico
    - - Pérdida de ventas
      - Pérdida de productividad
    - - Software de monitorización
      - Desactivar Firewall
  - - - Cuando el contenido solicitado ha sido borrado del servidor.
      - La petición fallo debido a una falla de una petición previa.
    - - El recurso que esta siendo accedido esta bloqueado.
    - - Se puede implementar un timeout en su espera por el mensaje de respuesta.
      - Reconocer mensajes sucesivos del mismo cliente y con el mismo identificador y poder filtrar los duplicados.
  - - - Falla en la capa de transporte.
      - No se encuentra a quien hizo la petición.
    - - El servidor no puede recibir el mensaje que estaba esperando para el cliente
    - - Realizar nuevamente la petición.
      - La primitiva de enviar puede bloquear al proceso hasta que se libere el canal y pueda depositar el mensaje.
- - - - En el lado del cliente validar en el ingreso del tipo de dato correcto.
        Verificar que el tipo de dato que se recibe es el adecuado.
    - - No se realiza la operación, y devuelve un mensaje de error.
        Se detiene el proceso o la operación.
    - - Se recibió un dato invalido para la operación que va a realizar, por ejemplo se esperaba un int y se recibió un tipo String
  - - - Cyberataque
      - Falla de electricidad
      - Avería de hardware
      - Sabotaje
    - - Los clientes no reciben el servicio
    - - Protección ante incendios y del suministro eléctrico
- - - - Empaqueta (marshaling) los argumentos del procedimiento remoto, los
        adecúa a algún formato estándar y construye uno o varios mensajes de red.
    - - Desempaqueta los argumentos de los mensajes de red y si es necesario, realiza alguna conversión, llama al procedimiento local(dispatcher).
    - - Rutinas estándar que serializan automáticamente datos de la mayoría de tipos: enteros, reales, cadenas, etc. Incluye rutinas adecuadas para serializar tipos de datos definidos por usuario.
    - - Definiciones de tipos constantes y procedimientos del stub del cliente y de
        las rutinas de servicios del servidor