¿Por qué no se construyen SMTP y HTTP en la parte superior del protocolo de transporte RPC?

¿Por qué no se construyen SMTP y HTTP en la parte superior del protocolo de transporte RPC?

Porque habría requerido una máquina del tiempo :

  • Primer SMTP RFC publicado en noviembre de 1981 [1]
  • Primera propuesta HTTP en 1989 [2] , primera definición pública en 1991 [3]
  • ONC (Sun) RPC implementado en 1984 [4] , RFC en abril de 1988 [5]

Claramente, RPC no era una opción para SMTP.

En cuanto a HTTP, si bien la línea de tiempo sugiere que podría haberse utilizado, el tiempo y la complejidad informática del desarrollo y la evolución de una infraestructura de entrega de documentos cliente-servidor RPC habrían sido considerables, teniendo en cuenta que las plataformas de servidores en ese momento eran mucho menos potente que el teléfono inteligente que llevas contigo ahora.

(Si no ha desarrollado una aplicación RPC no trivial, le recomiendo que comience con este tutorial, luego desarrolle su propia aplicación cliente-servidor desde esa base. Algunas cosas solo necesitan ser experimentadas … una vez).

También parece recordar que las implementaciones de RPC disponibles en ese momento (todas basadas en el propio código de Sun) no funcionaron bien en todas las redes de área amplia, lo que no es bueno para un protocolo destinado a soportar una World Wide Web . Los programas RPC que solía escribir, y los programas de mis clientes con los que todavía trato en ocasiones, están estrictamente basados ​​en LAN.

Finalmente, existen ciertas similitudes clave entre la sintaxis SMTP y HTTP, como su formato de argumento de comando delimitado por espacios y los códigos de estado de 3 dígitos. No me sorprendería si Sir Tim Berners-Lee considerara a uno como inspiración para el otro, por lo tanto, ni siquiera considerando HTTP-over-RPC.

Notas al pie

[1] Protocolo simple de transferencia de correo

[2] Protocolo de transferencia de hipertexto – Wikipedia

[3] El protocolo HTTP implementado en W3

[4] La larga y sórdida historia de Sun RPC, abreviada de alguna manera, para proteger a los astutos y los irresponsables.

[5] RPC: Especificación de protocolo de llamada a procedimiento remoto versión 2

RPC – Remote Procedure Calls () – es una técnica poderosa para construir aplicaciones distribuidas basadas en cliente-servidor. La intención de RPC era permitir que un programa en una máquina UNIX realizara una “llamada de función” a un programa que se ejecuta en otra máquina. Con RPC, la “función” podría residir en otra máquina UNIX que estaba en red. RPC es bueno para el programa UNIX-UNIX / Comunicación de proceso.

La comprobación de errores y el control de flujo son importantes para las aplicaciones basadas en HTTP (ahora HTTP2 / SPDY) y SMTP. Esto significa que TCP es un excelente candidato para HTTP / SMTP. La pila TCP / IP se puede implementar en cualquier sistema operativo.

RPC es más un protocolo de capa 5 (sesión), no de capa 4. También es un protocolo de capa 7 (aplicación). RPC en ese sentido en realidad se ejecuta sobre TCP.