Distributed Isolator

Introduction

The purpose of Isolator, my framework for running isolated (sandboxed) code is to be able to, well, run code (known as plugins) on distributed, isolated instances (hosts).

I initially created two isolation hosts:

  • Process (ProcessIsolationHost): a new process is created to host and run the plugin
  • Assembly Load Context (AssemblyLoadContextIsolationHost): a new assembly and assembly load context are created to host and run the plugin

Now I'm introducing a new one, that allows to execute code on another machine: ClientIsolationHost. I'll show you how to use it now.

Client Host Isolation

The idea is to be able to run code on a different machine, while keeping the same capabilities:

  • We pass an existing plugin instance to the host which is then handled transparently
  • Modified context properties are returned from the host to the caller
  • Standard output and error are also returned
  • The result value from the plugin's execution is returned too

We want to be able to specify a port, on the server end, and a host and port, on the client end. For that, we introduced a few new classes, besides ClientIsolationHost:

  • IsolationHostClient: client part, no need to explicitly use it, it is used behind the scenes by ClientIsolationHost
  • IsolationHostServer: server part, we need to use it
  • IReceiver/TcpReceiver: take care of the low-level reception (must match the transmitter), no need to worry about it
  • ITransmitter/TcpTransmitter: the low-level transmission (must match the receiver), no need to worry about it

Example usage follows.

On the server end:

using var server = new IsolationHostServer();
using var cts = new CancellationTokenSource();
await server.ReceiveAsync(port: 5000, cts.Token);
System.Console.ReadLine();

And on the client:

using var host = new ClientIsolationHost(host: "<someserver>", port: 5000);
var plugin = new HelloWorldPlugin();
var context = new IsolationContext();
var result = await host.ExecutePluginAsync(plugin, context);

Please note that on the server process, all you need to do is execute IsolationHostServer.ReceiveAsync. When you are done with it, just call Dispose or signal the CancellationToken parameter (more on cancellation tokens here).

As of now, it uses pure TCP/IP for communication, which means messages are turned into byte arrays and sent over the wire, but the mechanism is pluggable and more methods can be easily implemented.

The same ClientIsolationHost instance can be used to send multiple execution requests, of course, all to the same host and port. When you dispose of it, you will no longer be able to send requests. This class is used inside ClientIsolationHost so we generally don't need to worry about it.

Other Improvements

I made the serialisation process configurable, by means of a new abstraction, ISerializer, that only has a single implementation, IsolationJsonSerializer, that uses System.Text.Json. You don't need to do anything to use it, it is the default. The new TcpReceiver and TcpTransmiter use it.

Comparing With Other Hosts

Because this host is transmitting code to a (possibly) different machine, there is some latency involved. All should work the same, regardless of that. This one, of course, will provide a much higher degree of isolation.

Conclusion

All in all, I think this is a good addition to my framework. It is beginning to grow and add useful functionality. Code is already available in GitHub and in NuGet too.

It's missing some more error checks, ability to return exceptions, and maybe some polishing, possibly I'll make some changes during the next weeks.

As always, looking forward to hearing your thoughts!

Location: Coimbra, Portugal

Comments

Post a Comment

Popular posts from this blog

C# Magical Syntax

Introduction This post is an update to an old one on my  old blog  and it was inspired by my latest posts on C# versus Java . You may not have realized that some of the patterns that you’ve been using for ages in your C# programs are based on conventions, rather than on a specific API. What I mean by this is, some constructs in C# are based on some magical methods with well-defined names which are not defined in any base class or interface, but yet just work. Let’s see what they are. Enumerating Collections You are probably used to iterating through collections using the foreach statement. If you are, you may know that foreach actually wraps a call to a method called GetEnumerator , like the one that is defined by the IEnumerable and IEnumerable<T> interfaces. Thus, you might think, the magic occurs because the collection implements one or the two, but you would be wrong: it turns out that in order to iterate through a class using foreach all it takes is that the c...
Read more

OpenTelemetry with ASP.NET Core

Image
Introduction I wrote a post not too long ago about the building blocks of telemetry , or distributed tracing , with ASP.NET Core. Now I'm going to talk about how we can see it working using an open source bundle, otel-lgtm . Mind you, this may not be 100% suitable for production, but for development purposes, it should be fine, all concepts apply, of course. I won't cover everything about OpenTelemetry here, but should hopefully give you some insights as to what's there and how you can make good use of it. First, lets see what some of the concepts are. If you're interested in learning more about metrics, I suggest having a look at my post on this topic . OpenTelemetry OpenTelemetry  (OTel) provides a single, open-source standard, and a set of technologies to capture and export metrics, traces, and logs from your cloud-native applications and infrastructure. OTel is both a standard and a reference implementation that builds on other standards, such as W3C Distributed Tr...
Read more

ASP.NET Core Middleware

Image
Introduction This post is another of those "back to basics", still, there was one thing or two that I feel were not properly discussed elsewhere, hence this post. The ASP.NET Core Pipeline and Middleware You may know that ASP.NET Core defines a pipeline. This is where the incoming requests are processed and the response submitted. Each component in the pipeline - a middleware - can do things with the message (the request), such as check if it is authenticated and have rights to access the requested resource, turn the request into an MVC-style controller and action invocation, log it, and what not. You can read more about it here . The ASP.NET Core pipeline, from Microsoft The order by which the middleware is added to the pipeline matters. For example, the authorisation middleware must come after the authentication one, static files must come before routing, and exception handling must come before everything. The middleware order, from Microsoft A middleware is just a piece of...
Read more