Mmmux: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
K (repo umgezogen)
 
(10 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
[[Bild:Mmmuxd.png|thumb|250px|right]]mmmuxd stands for '''Multi Media Multiplexing Daemon''', which is a small daemon that basically accepts tcp connections and forwards incoming data to all other connected clients.
__NOTOC__
{{ProjektInfoBox
|name        = mmmux
|status      = beta
|image      =
|description = A multiplexing / abstraction library for easy hardware access
|author      = Soeren
|username    = Soeren
|version    =
|update      =
|platform    = anything that runs GNU/Linux
|license    = GPL
|download    = [https://github.com/soern/mmmux Git Repo]
<strike>[http://www.das-labor.org/trac/browser/mmmux Trac] [https://www.das-labor.org/svn/mmmux SVN]</strike>
}} __NOTOC__
[[Bild:Mmmuxd.png|thumb|250px|right]]
mmmux stands for '''Multi Media Multiplexing''' library, which is a small library that multiplexes hardware access to different devices (i.e. [[Rfm12usb]] and a yet-to-be-built canusb device) 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.
Whereas the term "multi media" often refers to 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 tcp packets - 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.
The mmmux is kept as small as possible for the sake of availability. By default, the mmmux 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 mmmux 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 mmmux 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. 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 ==
Zeile 9: Zeile 32:
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 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.
In order to connect our current infrastructure to the mmmux, a proxy program connects the cand service with the mmmux server. This way we can migrate the current infrastructure step by step.


== Operation scenarios ==
== 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.
The mmmux 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 may as well be used to '''forward data between different media''' and can easily connect canbus-speaking devices with radio transceivers.
Zeile 18: Zeile 41:
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.
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.


== Metainformation and modes of operation ==
== Security ==
In some scenarios it may be neccessary to cache requests or not forward packets from one medium to another and have some sort of routing for packets. The mmmuxd adds a special header containing the following information to each packet:
Of course this software is insecure and contains lots of bugs - especially at this early stage. 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).
* version -- protocol version
* speed -- speed at which the packet was received or is to be sent (in bit/s)
* frequency -- frequency on which the packet was received or is to be sent (in Hz)
* medium: medium from which the packet was received or is to be sent
* source ID
** ethernet: for client-to-client requests (i.e. requesting data from a connected proxy)
** canbus
** radio
 
Note that the fields for '''medium, speed and frequency''' may be set to <code>MEDIUM_ANY</code>, <code>SPEED_ANY</code> or <code>FREQ_ANY</code> for outbound packets, which implies that the given data is to be forwarded onto any medium, transmitted at the default frequency and/or at the default speed set for the respective transceiver.


The mmmuxd does not filter incoming packets - it will always forward packets to all connected clients. Instead, the clients that connect a certain medium with the mmmuxd need to filter whenever the medium field is set and not equal to the medium they are to forward packets to.
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 (<code>/tmp/mmmuxd.sock</code>) accordingly.


This occurs awkward at first sight, but is done for the following reasons:
== Adding new devices ==
* Clients may want to use multiple distinct media at the same time
In order to add a new hardware device handler, one needs to implement some or all of the 5 functions listed below. For reference, you may as well have a peek into [https://das-labor.org/trac/browser/mmmux/muxd_hw_rfm12usb.c muxd_hw_rfm12usb.c] and see how these functions are written, what their prototypes are and what they do.
* This way, mmmuxd doesn't need to be changed or restarted whenever a new media "adaptor" is connected to the daemon
* mmmuxd doesn't interfere with other layers or protocols, so it must not and doesn't have to be protocol-aware - think of it as a layer 2 transceiver


== Packet types ==
==== Initialization routine ====
There are 3 different packet types - these may be either one of '''inbound, outbound or internal''' packets.
This function is called when a new device is added or found. The function is optional and may only be of use for hardware devices that need initialization.


Packets arriving from a medium transceiver (i.e. CAN Bus) are referred to as '''inbound''' packets. Data which is meant to be forwarded to a certain medium is called '''outbound packet'''. The third packet type - the '''internal''' packet - is used to exchange messages in between the connected clients.
==== Send & Receive routines (aka rx and tx) ====
When data arrives from the client side, the send function is called. Likely, when data is available from the device, the rx function is used to gather it and send it to connected clients. Note that the rx function should be non-blocking and return 0 when no data is available. Values < 0 from both functions indicate errors and will result in a call to the close function, followed by the termination of the hardware task.


== Client Types ==
==== Close function ====
As mentioned before, there are 2 different client types: '''Normal''' clients, which are either sink or source for data packets and '''forwarding clients''' which forward data to a connected radio or can transceiver.
This function is used to properly close the connection to the device, turn it off and do whatever you need to do in order to close the link to the device.


Both client types use the same library (mmmux lib) to handle connections.
==== Find function ====
The find function is used to discover hardware devices - i.e. scan the usb bus and search for compatible devices. This function should then call <code>mmmux_hw_add()</code> in order to let mmmux know that there's a new device available. Mmmux will then start the hardware task and poll for data frequently.

Aktuelle Version vom 2. Januar 2015, 21:26 Uhr

       
mmmux

Release status: beta [box doku]

Description A multiplexing / abstraction library for easy hardware access
Author(s)  Soeren
Platform  anything that runs GNU/Linux
License  GPL
Download  Git Repo

Trac SVN




Mmmuxd.png

mmmux stands for Multi Media Multiplexing library, which is a small library that multiplexes hardware access to different devices (i.e. Rfm12usb and a yet-to-be-built canusb device) and forwards incoming data to all other connected clients.

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

The mmmux is kept as small as possible for the sake of availability. By default, the mmmux 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 mmmux protocol on the other - the same holds for radio transceivers etc.

API[Bearbeiten | Quelltext bearbeiten]

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 mmmux 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[Bearbeiten | Quelltext bearbeiten]

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 mmmux, a proxy program connects the cand service with the mmmux server. This way we can migrate the current infrastructure step by step.

Operation scenarios[Bearbeiten | Quelltext bearbeiten]

The mmmux 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[Bearbeiten | Quelltext bearbeiten]

Of course this software is insecure and contains lots of bugs - especially at this early stage. 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.

Adding new devices[Bearbeiten | Quelltext bearbeiten]

In order to add a new hardware device handler, one needs to implement some or all of the 5 functions listed below. For reference, you may as well have a peek into muxd_hw_rfm12usb.c and see how these functions are written, what their prototypes are and what they do.

Initialization routine[Bearbeiten | Quelltext bearbeiten]

This function is called when a new device is added or found. The function is optional and may only be of use for hardware devices that need initialization.

Send & Receive routines (aka rx and tx)[Bearbeiten | Quelltext bearbeiten]

When data arrives from the client side, the send function is called. Likely, when data is available from the device, the rx function is used to gather it and send it to connected clients. Note that the rx function should be non-blocking and return 0 when no data is available. Values < 0 from both functions indicate errors and will result in a call to the close function, followed by the termination of the hardware task.

Close function[Bearbeiten | Quelltext bearbeiten]

This function is used to properly close the connection to the device, turn it off and do whatever you need to do in order to close the link to the device.

Find function[Bearbeiten | Quelltext bearbeiten]

The find function is used to discover hardware devices - i.e. scan the usb bus and search for compatible devices. This function should then call mmmux_hw_add() in order to let mmmux know that there's a new device available. Mmmux will then start the hardware task and poll for data frequently.