Mmmux: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
KKeine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
Zeile 9: Zeile 9:
From the programmer's point of view, the API is pretty simple and not hard to understand. First of all, you need to initialize a mmmuxd context with <code>mmmux_init()</code>. Right after that, you can send and receive data from this context with the functions <code>mmmux_send()</code> and <code>mmmux_receive()</code>.
From the programmer's point of view, the API is pretty simple and not hard to understand. First of all, you need to initialize a mmmuxd context with <code>mmmux_init()</code>. Right after that, you can send and receive data from this context with the functions <code>mmmux_send()</code> and <code>mmmux_receive()</code>.


What the mmmux implementation in the background does, is fork a process (server) that handles incoming data and forwards it to the device or connected clients respectively. When starting, the process searches for hardware devices it can get a grab on and tries to use them. Whenever the daemon discovers a new device, it starts another process (hardware handling task) in order to process data from and to the device without delays.
What the mmmux implementation in the background does, is fork a process (server) that handles incoming data and forwards it to the device or connected clients respectively. If the server is already running, thus was invoked by another application using  the mmmux library, the <code>mmmux_init()</code> function will just connect to the existing server.
 
When starting, the process searches for hardware devices it can get a grab on and tries to use them. Whenever the daemon discovers a new device, it starts another process (hardware handling task) in order to process data from and to the device without delays.


== Migration from current Infrastructure ==
== Migration from current Infrastructure ==

Version vom 30. Januar 2012, 22:52 Uhr

Mmmuxd.png

mmmuxd stands for Multi Media Multiplexing Daemon, which is a small library that multiplexes hardware access to different devices (i.e. Rfm12usb) and forwards incoming data to all other connected clients.

Whereas the term "multi media" often stands for fancy graphical eye-candy stuff, it in this case means "connecting different transport media", such as can-bus, radio transceivers and ethernet.

The mmmuxd is kept as small as possible for the sake of availability. By default, the mmmuxd only forwards data on a local (unix) socket - in order to connect an additional medium (such as canbus), one needs to have a client that implements the hardware interface to the canbus device on one side and the mmmuxd protocol on the other - the same holds for radio transceivers etc.

API

From the programmer's point of view, the API is pretty simple and not hard to understand. First of all, you need to initialize a mmmuxd context with mmmux_init(). Right after that, you can send and receive data from this context with the functions mmmux_send() and mmmux_receive().

What the mmmux implementation in the background does, is fork a process (server) that handles incoming data and forwards it to the device or connected clients respectively. If the server is already running, thus was invoked by another application using the mmmux library, the mmmux_init() function will just connect to the existing server.

When starting, the process searches for hardware devices it can get a grab on and tries to use them. Whenever the daemon discovers a new device, it starts another process (hardware handling task) in order to process data from and to the device without delays.

Migration from current Infrastructure

Mmmuxd migration scheme.png

In our current implementation we have a canbus daemon (cand) that connects the canbus transceiver hardware with the tcp protocol. Programs that need to talk to canbus devices connect via tcp to the cand, which then forwards data from and to the bus.

In order to connect our current infrastructure to the mmmuxd, a proxy program connects the cand service with the mmmuxd. This way we can migrate the current infrastructure step by step.

Operation scenarios

The mmmuxd may be used to multiplex access to a single media transceiver - such as rfm12usb. This way one may use a single hardware device with several different applications at a time - this was the primary implementation goal.

It may as well be used to forward data between different media and can easily connect canbus-speaking devices with radio transceivers.

It can be used to connect distant canbus/radio networks with one another - for example connecting two canbus networks via ethernet in scenarios where otherwise the cable length would be over the specifications for safe operation.

Security

Depending on the system's configuration, it may be necessary for a user to start the mmmux implementation as privileged user (root in most cases). Whenever possible, the implementation grabs a handle to the device and then chroot's itself to a temporary directory and changes GID and UID to some random number (> 30.000).

As far as local sockets are concerned, neither encryption, nor further access control is applied (the latter is planned). In order to apply some level of authentication, you may want to manually set permissions to the socket (/tmp/mmmuxd.sock) accordingly.