Next picture displays the architecture and communication protocolls of MACS. We can figure three parts: The system core, the control unit and the unit under control.
The global structure
The system core is build off the controler and connector scripts which actually are parts of the control unit and the unit under control. This way the systm core is able to open a communication channel betweem both units.
The control unit is build of a number of control modules which can exchange messages and send commands to the unit under control by using the core.
The unit under control again is build off a number of prims runing processor scripts which perform required tasks. These tasks are triggered by commands from the control unit or other processors.
In the whole tutorial the words 'message' and 'command' are used synonymically: A command is a message forcing any action and transporting data (command parameters), required for that action.
System core, core services
Controller and connector scripts define a core of the system. As seen in the figure, only that both scripts are connected directly. This is important. All messages betweem both units must pass these scripts. The reason is security, given by the system. One can for sure write modules and processors communicating around the core, but we will never handle that way in near future.
The system core offers three services to processors and control modules, message transport service, touch to message service and autoresponse service.
Message (and data) Transport Service
The MTS is sometimes meintoned by controller-connector bridge, or just bridge. This service takes a MACS message on the sender side and if the message passes all security checks, it is inserted unchanged into the receiver unit, as if both units were linked together.
The physical transport medium between both units is chat (the simplest way to transfer messages). That chat messages build a security frame: It denotes what object the sending unit is, who is operating it, what object is the message target, the send time and a key to validate the sender.
This connection is directed, with multiple broadcasting levels: The control unit can send messages to each device in range, to each device given a special alias, to each device belonging to special avatar or to devices with special alias, owned by special avatar. The unit under control sends responses to the control unit given by key.
The connection is verified to be sent by a valide MACS device and to be not manipulated. MTS ensures that the person, named as operator of the sending unit really operates it. The unit under control can accept or decline the commands due to the sending control device, the identity of it's owner or the person, operating it.
For incoming commands the system supports various access levels, like owner-only, group access or restricted by whitelist.
Touch to message service
The T2MS is working locally inside the control unit and intends to reduce the amount of scripts and also to accelerate developing of simple control modules. Control modules control another and the unit under control by sending commands. Some of that modules generate statical messages that never change (a command to enlarge the boots by 50% is always the same message for instance) .
T2MS allows to make such modules completelly unscripted. If a prim is touched and the touch event reaches the controller script, the name of the touched module is converted into a MACS message and performed if required. Modules that generate statical messages have to be just unscripted prims, that are properly named and linked to the control unit.
The ARS again is a local service inside the unit under control. This service requires all commands to be registered before they can pass the bridge: The connector script will simply decline unregistered commands. The command registration is the job of processor scripts, as they only know what they can execute at all. All that commands can be registered together with a status.
When the connector script receives a command with an assigned status, a response message is generated and returns the assigned status back to the control unit. The reason for this service is simple: The processor script might be not able to generate this response in time being just busy with executing another command. After it becomes free to receive commands, it has simply to actualize the registered command status.
There is even more. If a declining or 'busy' status is assigned to a command, and this command is received, the connector script sends this status back in the response but does not rely the command to processors. They would not execute it at all.
In the next part
Ok, what we had is the pure therory. The MACS is a poverfull tool but as introduced it will not be able to do much. Its services are useless without control modules and processors. To make the system practically usable, a so called System Development Kit was been developed. It contains a special processor and control modules that are developed in transforming attachments in mind.
Introducing the SDK will need again much place, so it will be separated in further parts, the first one will handle the special procesor and messages it understads and another parts will be about control modules generating those messages.