Remoting Server-Side

When the Windows Service was successfully running, a way had to be found to control it. There was a ServiceController class which allowed controlling a service and sending messages to it trough the ExecuteCommand method. This method was limited to sending integers without getting anything back. A better solution was to use Remoting to control the service.

Remoting allows for interproces communication, making objects available between different processes. An object is passed from server to client by reference, where the client can work with it as if it was a real object at the client. Remoting takes care of collecting information about the client calls and sending it to the server, where it is passed to the server object which performs the action on the client’s behalf. The result of this operation is then sent back to the client.

Remoting can transport this information over different channels, such as TCP and HTTP for example. In the project, a TCP channel was used, with the following code:

 

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Tcp;

 

namespace MediaService.Player {

  public class PlayerService : System.ServiceProcess.ServiceBase {

    private TcpChannel tcpChannel;

 

    private void SetupRemoting() {

      this.tcpChannel = new TcpChannel(this.configData.RemotingPort);

      ChannelServices.RegisterChannel(this.tcpChannel);

      RemotingConfiguration.ApplicationName = "MediaServicePlayer";

 

After a channel had been setup, there were different possibilities to make a certain object available. But first, the object had to be created. This was a simple class, which inherited from MarshalByRefObject, and implemented a custom interface.

 

using System;

namespace MediaService.Player {

  public class PlayerServiceController:  MarshalByRefObject,

                                         IPlayerServiceController {


The interface was used, to make it possible to only make the assembly with the interface available to consumers of the remote object, instead of the implementation.

After an object was created, it was possible to register this type as a WellKnowType. There were two possibilities for this. It could be registered as a Singleton, which would make sure only instance of the object lived on the server at a given time. The other possibility was to register it as SingleCall, which would create a new object for each call. None of these two proved to be successful, because they both were unable to call methods from the service. The solution was to instantiate a new object when the service started, and to make this instance remotely available. This allowed the object to be in contact with the Windows Service, making it possible to control it. The following code published the object on tcp://host:port/MediaServicePlayerController:

 

RemotingServices.Marshal(this.playerController,  

                         "MediaServicePlayerController");


At the end, when the service was stopped, everything had to be cleaned up. The published object got disconnected and the channel got unregistered.

 

private void TearDownRemoting() {

  RemotingServices.Disconnect(this.playerController);

  ChannelServices.UnregisterChannel(this.tcpChannel);

} /* TearDownRemoting */

2 Comments

  • what is actually the difference between a singleton type and the solution "instantiate a new object when the service started".



    Isn't that the same thing?

  • I have several questions about this:



    1. Did you use events in the remote obejct to let the service know that the client wanted it to change state?



    2. Can you use the same object to reflect state (ie pass current state information back to the client)?



    3. If you wanted to expose more than one remote class do you have to use a different Channel for each or can you publish them on the same channel?



    4. Would you mind showing your complete source code?



    Thanks for the help





    Ian

Comments have been disabled for this content.