Limitaciones de mecanismo SunRPC como una arquitectura cliente-Dispatcher-servidor y la comparación con Broker

Question

Estoy leyendo un libro sobre patrones de diseño (una vieja edición) " patrón-orientado arquitectura de software ". En el capítulo dedicado al cliente-servidor-Dispatcher, SunRPC se cita como una arquitectura cliente-servidor-Dispatcher, con portmapper actuando como despachador en la negociación entre cliente y servidor. Nunca había usado SunRPC prácticamente, a pesar de que sé más o menos cómo funciona.

Tengo tres preguntas:

• ¿Cuáles son las limitaciones de software (en términos de interfaces y funciones) de SunRPC como un mecanismo de cliente-servidor Dispatcher-?
• ¿Cuáles son los mejores sistemas similares en la actualidad para lograr la misma arquitectura cliente-servidor-Dispatcher (independientemente del idioma)?
• ¿Cuáles son las diferencias intrínsecas entre una arquitectura Broker y una arquitectura cliente-servidor Dispatcher-?

Me doy cuenta de que las preguntas son muchas y complejas. Consideré la división en cuestiones independientes, pero el objetivo de esta presentación es sobre los principios generales y las limitaciones de arquitectura, con un ejemplo específico (SunRPC) como un caso típico. Debido a estas consideraciones me preventivamente anuncio que voy a poner una recompensa de 100 rep tan pronto como tengo la oportunidad, a pesar de mi nivel de satisfacción con respuestas durante el período de gracia.

Answer 1

Esta terminología es poco común (al menos para mí), tal vez esa es la razón por la que no está recibiendo muchas respuestas. A juzgar por la diagrama de la página 327 , medios cliente-distribuidor-servidor que una redirección al servidor real se produce en el momento de la conexión, mientras que se interpone en todo el corredor de comunicación ( página 109 )? Suponiendo que, hoy en día los términos serían "redirección" (o "servicio de nombres" o "servicio de directorio", etc), y "proxy", respectivamente. La diferencia principal es un compromiso entre la latencia y la disponibilidad, es decir, los corredores están en una posición para arreglar las cosas cuando un servidor troqueles, que despachadores no lo son; pero los corredores de añadir un poco de tiempo de procesamiento de la tubería.

casos moderna de ambos patrones se puede encontrar en los sitios Web de alto volumen: por lo general se empleará un round-robin o más sofisticado balanceo de carga servicio DNS (despachador), así como el almacenamiento en caché proxies inversos (corredores) .

No sé mucho acerca de SunRPC y sus limitaciones, y no tengo ni idea de si es, posiblemente, puede ser utilizado en una especie de round-robin de forma (búsqueda en Google de " carga portmap equilibrio " vueltas a nada Fwiw). Una entrada en la mesa del portmapper típicamente apuntará a un único servidor que se ejecuta en el mismo huésped, es decir, sobre todo este mecanismo sirve para evitar la asignación puertos TCP conocidos a los servicios sunrpc.

Answer 2

Eso es un buen conjunto de preguntas. Usted podría intentar lista de los Siemens-patrones servir como uiuc. Lo último que supe que era bastante bajo volumen pero había un número de personas afilados allí, incluso algunos de los autores. Que se puede pedir y compartir su iluminación.