Chapter 9: Extending .NET Remoting

Overview

IN CHAPTERS 7 AND 8, I told you a lot about the various places that can be extended by custom sinks and providers. What I didn't tell you is why you'd want to change the default remoting behavior. There are a lot of reasons for doing so:

• Compression or encryption of the message's contents

• Passing additional information from the client to the server. For example, you could pass the client-side thread's priority to the server so that the remote execution is performed using the same priority.

• Extending the look and feel of .NET Remoting. You could, for example, switch to a per-host authentication model instead of the default per-object model.

• Debugging your applications by dumping the message's contents to the console or to a log file.

• And last but not least, custom sinks and providers enable you to use other transport mediums such as MSMQ or even SMTP/POP3

You might ask why Microsoft didn't already implement these features itself. The only answer I can give you is that most programmers, including myself, really prefer being able to change the framework and add the necessary features themselves in a clean and documented way. You can look forward to getting message sinks from various third-party providers, including Web sites from which you can download sinks with included source code.