When a method call is made on the proxy, the remoting infrastructure provides the necessary support for:
Passing the arguments to the actual object across the remoting boundaries.
Calling the actual object method with the arguments.
Returning the results back to the client of the proxy object.
A remote method call is defined in terms of a Message that goes from the client end to the server end and possibly back again. As it crosses interesting boundaries on the way, it passes through a chain of MessageSink objects. Each sink in the chain receives the Message object, performs a specific operation and delegates to the next sink in the chain. The Proxy object contains a reference to the first MessageSink it needs to use, to start off the chain.
For asynchronous calls, at the time of delegation, each sink provides a ReplySink (another MessageSink object) that will be called by the next sink when the reply is on its way back.
The nature of the operation performed by a MessageSink when it receives a Message object to process may be radically different for different types of sinks. For example, one sink could cause a lock to be taken, another could enforce call security, another could be performing flow call control/ reliability services and yet another could be responsible for transporting the call to a different AppDomain/ process/ machine. Two or more message sinks in the chain may communicate and interact with each other in regard to each specific action.
IMessageSink
[Visual Basic] Public Interface IMessageSink [C#] public interface IMessageSink [C++] public __gc __interface IMessageSink
[JScript] In JScript, you can use the interfaces in the NGWS frameworks, but you cannot define your own.
Class | Description |
---|---|
LeaseSink | ???????????????????????????????????????? |
[To be supplied.]
Namespace: System.Runtime.Remoting
Assembly: mscorlib.dll