Game Development Reference
by first instantiating either TcpServerChannel or HttpServerChannel , depending on
the protocol you wish to use. The constructor accepts the port number that this
channel resides on over the protocol used.
The server application must reference the shared vocabulary assembly so that the remote object
definition is available to the server.
TcpServerChannel serverChannel = new TcpServerChannel(9978);
This code creates a Remoting channel on port 9978 using the Tcp protocol. The
following code shows the same thing using the Http protocol.
HttpServerChannel serverChannel = new HttpServerChannel(9978);
After the channel is initialized, it must be registered with the static ChannelServices
object, used in the registration of Remoting channels, resolution, and URL discovery.
After the channel is registered, it is time to register the vocabulary so that clients
can begin requesting the proxy objects. This is done using the static
RemotingConfiguration object, used for configuring the Remoting infrastructure.
Remote object lifetime management is an important factor to consider when
designing your system. There are two lifetime types available to remote objects:
SingleCall and Singleton . SingleCall means that every incoming message will be
serviced with a new instance of the registered type. Singleton means that every
incoming message will be serviced with a shared instance of the registered type.
Since our object does not even have variables to store data, it would be most effi-
cient to use a singleton instance of the remote object. We call RegisterWellKnown
ServiceType to register our class as a well known type on the service end.
That's it! The server has been created and is now making our remote object vocab-
ulary accessible to any clients that request it. The last step is to create the client
application that will use the remote object.
Creating the client is even easier than creating the server; the remote object can be
accessed using just one line of code!