.net clr remoting

.net - ¿Es especial MarshalByRefObject?



clr remoting (2)

Creo que MarshalByRefObject no es tan especial. Creo que todo su motivo de existencia radica en su gestión de por vida y en la recolección de basura en el servidor. Hay algunos buenos comentarios sobre de qué se trata esto en la documentación de la clase LifetimeServices .

AFAIK, la verdadera magia de la comunicación remota la lleva a cabo la infraestructura remota cuando configuras los hosts. MarshalByRefObject no está haciendo el trabajo real de ordenar cosas en AppDomains.

.NET tiene una cosa llamada "comunicación remota" en la que puede pasar objetos entre aplicaciones separadas o incluso máquinas físicas. No entiendo completamente cómo se hace la magia, de ahí esta pregunta.

En remoto, hay dos formas básicas de pasar objetos, ya sea que se pueden serializar (convertir a un grupo de bytes y reconstruir en el otro extremo) o pueden heredar de MarshalByRefObject , en cuyo caso .NET realiza algunos proxies transparentes y todo las llamadas a métodos se reenvían a la instancia original.

Esto es genial y funciona como magia. Y no me gusta la magia en la programación. Al mirar el MarshalByRefObject con el reflector, no veo nada que lo diferencie de cualquier otro objeto típico. Ni siquiera un atributo interno extraño ni nada. Entonces, ¿cómo se organiza todo el proxy transparente? ¿Puedo hacer ese mecanismo yo mismo? ¿Puedo crear un MyMarshalByRefObject alternativo que no herede de MarshalByRefObject pero que siga actuando de la misma manera? ¿O es que MarshalByRefObject recibe algún tratamiento especial por parte del motor .NET y toda la proeza remota no es duplicable por meros mortales?

La magia parece estar en una clase especial TransparentProxy : .NET Runtime lo maneja de una manera especial.

Creo que MarshalByRefObject puede contener información interna adicional que puede ser útil para este mecanismo, pero no he investigado mucho sobre eso.