Chapter 6: Building a Distributed Task Manager

Overview

The Remoting Framework developed over the last few chapters isn't limited to messenger-style applications. In fact, it may be better suited for an entirely different type of application: a distributed supercomputer.

One of the best-known examples of this type of application is SETI@Home, which harnesses the power of idle personal computers to digest large amounts of astronomical data in search of unusual signals. SETI@Home, like the messenger application we've created, isn't a pure peer-to-peer application—it depends on a central server that plays a key role in coordinating the entire system, and it doesn't make use of any peer interaction. Nevertheless, the bulk of the actual work is performed at the edges of the network, by ordinary peers.

This type of distributed processing works well with the Remoting architecture because it doesn't require frequent interaction across the network. Typically, peers will run independently to perform their work, and messages will only be exchanged when starting or completing a task. Thus, the higher-level object abstraction that Remoting uses is perfectly suitable. In fact, inventing a proprietary messaging format and communication protocol for this sort of system might just be overkill.

In this chapter you'll look at how to build your own peer-to-peer task processor system for specific tasks and how to extend the system to handle dynamically defined task types. Along the way, you'll also consider how .NET code-access security allows you to build a better sandbox and execute user-supplied code without risking the threat of Trojans, viruses, and worms.