NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Remoting High level Overview

The Runtime provides an environment where objects can make method calls and access properties and fields on other objects. Generally speaking, when the caller and callee object instances are both within the same boundary, method calls occur directly from the caller instance to the callee instance. When method calls occur between objects instances across a boundary, Base Remoting is used. These boundaries include calling between: contexts, application domains, processes and machines.

Figure 1: Contexts and Base Remoting Infrastructure Model.

Runtime types (classes) can have methods, properties and fields. The purpose of Base Remoting is to present the illusion that what is being called locally has the same type (class) as the remote instance. The application can be deployed and configured by an administrator to run local or remote.

Remoting stages

Let us discuss by way of an example how an operation on a transparent proxy is forwarded to the remote object it represents. For the purposes of discussion below we will assume that the “client” object obtained a transparent proxy, by some means, to a “server” object living in a different process on the same machine.

Figure 1: Remoting stages: outlines various stages involved in processing a call made by a client on a proxy and forwarding it to the server object.

Packaging stage

The transparent proxy has two method tables: a forwarding method table that the client’s calls are routed into and the Proxy object’s method table, which is just the regular method table for any managed object.

When a client invokes a method on transparent proxy, control reaches a forwarding thunk present in the forwarding method table. Utilizing the method signature, the forwarding thunk captures the stack frame representing the call, encapsulates it inside a Message object and delegates to the message sink stored inside the proxy object by passing it the message. If the method represents an asynchronous call a reply sink object is created and is also passed. If the method represents a one-way message, the reply sink will not be created or passed.

When the reply message arrives, the return and out parameters are propagated from the reply message to the client memory locations and the call is marked as complete.

Processing stage

Message sinks are responsible for carrying message object from their source to the destination. The message object is serialized for transportation across the boundary via a channel. This may utilize object Formatters to serialize object references inside message object depending upon how far the message is going from a remoting standpoint. The Formatters are pluggable into the channel. For example a HTTP channel can have many formatters plugged in (e.g. XML Formatter, Binary Formatter etc). These same Formatters can be plugged into another channel (e.g. TCP Channel).

Message sinks processing one-way messages may return the client thread before completely dispatching the message.

When the reply message arrives on the reply sink, return/out parameters are propagated to the client memory locations. Object references are serialized / deserialized as needed.

Dispatch stage

A dispatcher / stack builder object that appears as a message sink to its clients, accomplishes this stage. It sets up an exception handler and invokes the method on the server object. It then calls the reply sink supplied by its caller by passing it the reply message generated as a result of the call invocation. If something goes wrong, the reply message will contain information about the Exception.