mBrane Page on Mindmakers | Discussions | Source Code on SourceForge
Overview
mBrane is a registration-based message routing framework, where distributed and loosely coupled components can register for and post data, either as discrete messages or as continuous steams. It is designed primarily to be an extremely fast communication system where routing is done by local network nodes directly and routing information is updated near instantaneously and globally. The target performance goal is - to the minimum - to consistently achieve 1 message/module every 10msec for 100 modules.
mBrane shall be simple, easy and target only the basics of efficient and uncompromising message routing. The opposite case in point would be CORBA/DDS, with its multi-layered architecture and high overhead. From an architectural perspective, we take an opposite view in mBrane where, when a feature is needed it shall be wedged-in (and in that respect the time expenditure for extra features shall remain accounted for, see below) instead of layered on top of the existing code base.
mBrane is intended for an audience of experimented programmers, and shall remain as Spartan - and efficient - as may be. We shall avoid feature bloating and instead, strive for both performance and scalability - possibly trading payload complexity for streamlined design and coherency at the overall system scale, e.g. homogeneity (semantics and granularity) in the application design.
In particular, and on the tech side, our main foe is latency.
Real time operation: operating in real time means to guarantee the execution of code in a time that is commensurable to the Universal Time. It does not mean to be fast, it means to be accurately accountable for time so that code can actually take contingency measures towards achieving execution in prescribed boundaries. We are using non real-time operating systems so, how can we target real-time operation? In the main, by giving the developer a thorough accountancy of time expenditures, that means, for every message passing, giving the time expenditure within the timer resolution. Guaranteeing time expenditure of the overall computation remains however the job of developers. Since the primary network target (Gb ethernet) is non deterministic, mBrane will provide the best effort in routing. Developers, on their side, shall provide the best effort in bounding code execution, for example in planning, by trading accuracy for time-bound responses (in other words, by providing the outline of a plan while leaving the details to be computed while the first steps of the main plan are actually enacted). In the end, all of this will be messed up by the OS scheduler: we (mBrane designers and application developers) shall contain this effect within accountable boundaries using accurate time measurements of both routing and computing. In that respect mBrane has to limit jitter in scheduling to increase predictability.
