Blanket.NET and Spongy Interfaces!

Had lunch today with Joel P and Franky at the best Yum Cha restaurant this side of The Great Wall, and we got onto the topic of concurrent .NET. This opened up the discussion around an idea myself and Nigel Watson cooked up one day while talking pie, and chatting with Joel P moved it one step closer from the sky to the IDE.

See, the idea goes by the name of Blanket.NET, and is based on a concept we call “spongy” interfaces (quite sure the concept probably exists under another name somewhere in the galaxy). So, it goes a little something like this:

Blanket.NET is a firstly a runtime that is deployed to one or many multi-core, multi-proc servers. The runtime supports a declarative framework which enables developers to decorate a class as being “spongy”, but we’ll get to what “spongy” means later. So, now this class is marked as kinda like [Blanketed].

You then deploy the component to any server “under” the blanket. The runtime immediately picks up a change under the blanket, and communicates via some kind of channel (this should be abstracted, so to provide binary and text protocols, but all should be stingy as) to the other “nodes” under the blanket, communicating the composition of the component. Now, it doesn't transmit the whole components, just a set of lightweight instructions that enable the other frameworks to compose a copy of this object, it won’t be the identical object, just a composition (or imitation). Why? Well, generally most of the code in a component is made up of repeating patterns, so transmitting the same line of code 15 times is a waste, or even 15 instances of a text pattern in code, so you assemble a way of recreating the component from repeated patters. So, now each time something changes under the blanket, the runtimes sync, and while they’re sync'ing, all calls to the blanket get queued by the “stitching”, which is part of the runtime that handles queueing messages while the blanket is unavailable.

Next, what is this spongy business? Well, you make a call into the blanket for 1..N component instances of a class or type, say Customers. When you make the call, you indicate to the blanket how many copies you want working, and whether they should be exclusive or shared. If they are shared, the areas decorated with the [BlanketShared] are sync, if exclusive, each component runs in isolation. Communication is all done through delegate callbacks.

OK, now this is what I reckon is the cool stuff. The blanket is hooked into the low level hardware, and can develop heat maps around core and processor performance (and workload). When you ask for say, 15 StockPriceCalculator instances, then give them some values to compute, the blanket looks to the “under” nodes, and instructs components across those servers to perform. During this process, each component registers with the local machine blanket runtime a set of service level counters, and should the server that component instance is executing on be unable to meet that SLA, the blanket looks for another node, and simply passed the execution context and callback ref over to that node to complete processing. Why? ‘Cos then you have a highly dynamic, hot scalable. transparent way of managing your workhorse components. And all developers have to do is simply mark their code with some attributes. Also, for your projects, you simply invoke a VS add-in that queries the blanket for current components, and builds the dynamic collars into your project App_Code folder so you can make the calls. This can be designed to be refreshed each time the blanket environment changes.

Phew! Anyway, at this stage its just an idea a couple of us are kicking around, but I’d love to hear from anyone and everyone about what this could mean to them, and how it could be built upon. Just some Friday funsies to end the week if nothing else 🙂

Comments (6)

  1. Waw! Great idea! So where are sources ;)?

    btw. I’m working on something like this project (but only something like ;)), but for communication with 1 server based somewhere in 1 PC, and many clients on pocket PC, handhelds, and PC. My project is like XFree, Citrix, VNC but with different screen drawing using paint commands (like these in GDI+).

  2. MSDN Archive says:

    Have you seen MC#? It’s a modified runtime and C# variant to create "movable" methods.  It’s geared toward distributed computing.  Similar to what your proposal looks like,  I think.

  3. davidlem says:

    Hey Keith, checked out the MC# home page, looks very interesting. I like the way they discuss movable methods, as I suppose the whole crux of this kind of framework would rely more on the passing of delegates for concurrency than the whole object. But the concept of making an object "dead" seems a little wasteful. I like the idea of the object instance being valid as it’s passed from one node to another, similar to the concept or transportation, as soon as the replica has been successfully assembled on the target, the original is destroyed, and the replica assumes the role of original.

Skip to main content