¿Cuál es el problema con la llamada a procedimiento remoto?

Una llamada a procedimiento remoto permite que un programa en una computadora invoque una función en un programa en otra computadora.

Permite que varias computadoras actúen como un sistema más poderoso. A menudo, cada computadora se optimizará para un propósito específico. Y tener un sistema compuesto por varias computadoras puede permitir un mantenimiento más fácil mientras se mantiene el tiempo de actividad del servicio (al tener redundancia para que los servidores individuales se puedan desconectar sin afectar el sistema), y permite mucho más margen para la escalabilidad y el procesamiento paralelo (al tener múltiples computadoras que pueden hacer cada tarea y compartir solicitudes entre ellas).

Probablemente podría lograr resultados similares simplemente intercambiando datos de forma asincrónica y procesando periódicamente esos datos, pero las llamadas a procedimientos remotos permiten que el intercambio y el procesamiento se realicen de forma sincrónica (en tiempo real a pedido) y que los resultados se devuelvan de inmediato.

Cuando dos máquinas deben colaborar desde extremos opuestos de un cable, básicamente pueden hacerlo utilizando mensajes pasivos o activos.

Los mensajes pasivos solo requieren una instalación de copia de datos, y deja la responsabilidad de coordinar la transmisión y recepción a la lógica del programa de las aplicaciones en ambos extremos. El resultado es una capa de middleware muy delgada con pocas responsabilidades, a costa de poner un poco de protocolo personalizado en una lógica de aplicación más complicada.

Los mensajes activos (esencialmente, llamada a procedimiento remoto) crean la ilusión de que un lado puede hacer que las cosas sucedan en el otro extremo enviándole una señal unilateral. Esto carga al middleware con la responsabilidad de incluir un servicio para recoger mensajes en cualquier momento y descifrar qué activar en respuesta a ellos, por lo que se vuelve más complicado. El código de la aplicación se vuelve más ágil, ya que los detalles de implementación de recepción y despacho ya no son responsabilidad directa del programador. En el lado negativo, el servicio de gestión de señales / middleware debe ser más general que los intercambios específicos de la aplicación (y, por lo tanto, más grande), ya que no necesariamente puede saber de antemano qué mensajes vendrán en qué orden.

La comunicación unilateral a menudo se considera un poco más fácil en los cerebros de los programadores de aplicaciones, por la misma razón que el paralelismo de memoria compartida es; le quita la mitad del negocio de la comunicación al código de la aplicación, a costa de algunos gastos generales del sistema, para automatizarlo de manera general. Lo importante que es esto realmente se reduce a cuánto dolor habría en escribir recepciones y explicar todo, lo que a su vez depende de la complejidad de la aplicación.

Para mí, realmente me gusta la comunicación unilateral, debido a la cómoda simplicidad de solo enviar cosas y considerar el asunto cerrado. Sin embargo, incluso si es muy suave cuando la corrección del mecanismo RPC subyacente es un problema de otra persona, en realidad es algo algo complicado bajo el capó y tiende a tener un costo de rendimiento medible. Yo diría que lo más importante de RPC es ser consciente de lo que da a cambio de lo que obtiene y disfrutar de sus beneficios según corresponda.

Para resumir Matt Langley, se trata de conveniencia y simplicidad. Cuando se aplica a sistemas complejos grandes, incluso un par de puntos porcentuales en delta (ganancia o pérdida, según cuál sea mejor) se convierte en un “gran problema”.

“Acción a distancia” es la respuesta de una línea.

Es divertido que te hagan esta pregunta. Mi jefe de la Red del Espacio Profundo (Angie) conocía al tipo (Bruce Jay Nelson) que escribió la primera tesis doctoral (1981) sobre el tema. Nunca me presentaron a Bruce, pero tenía una copia de su tesis doctoral (un PARC Azul y Blanco como se llamaba a sus informes técnicos) ahora en el Museo de Historia de la Computadora si no lo han descartado (completamente posible). La otra persona que puedo pensar que conocía a Bruce bastante bien es John Schoch.

RPC es más importante que los procesos fork (2) ing (que por defecto se presumen locales), ya que tienen un efecto fuera de los límites del espacio de direcciones local. RPC solo se volvió realmente significativo cuando la comunicación fuera de las computadoras se volvió significativa.

Decir esto no responde a problemas complejos inherentes a todas las llamadas de procedimiento (llamadas de subprograma) como paso de parámetros, paso de estructura de datos complejo, etc.: estado del programa que puede volverse complejo durante minutos de luz u horas de luz. O pronto días de luz.

¿Esto responde a tu pregunta?

Es un concepto abstracto que dice que puedes hacer que otro proceso haga algo. No hay gran cosa El mayor negocio es lo productivo que eres.