Mmmux: Unterschied zwischen den Versionen
Soeren (Diskussion | Beiträge) K (Änderungen von Bg (Diskussion) rückgängig gemacht und letzte Version von Soeren wiederhergestellt) |
Soeren (Diskussion | Beiträge) KKeine Bearbeitungszusammenfassung |
||
Zeile 22: | Zeile 22: | ||
* version -- protocol version | * version -- protocol version | ||
* speed -- speed at which the packet was received (in bit/s) | * speed -- speed at which the packet was received (in bit/s) | ||
* frequency -- frequency on which the packet was received (in | * frequency -- frequency on which the packet was received (in Hz) | ||
* medium: medium from which the packet was received (or is to be sent if "stick to mediun" flag is present) | * medium: medium from which the packet was received (or is to be sent if "stick to mediun" flag is present) | ||
* source ID | |||
** ethernet: for client-to-client requests (i.e. requesting data from a connected proxy) | ** ethernet: for client-to-client requests (i.e. requesting data from a connected proxy) | ||
** canbus | ** canbus | ||
** radio | ** radio | ||
The mmmuxd does not filter incoming packets - it will always forward packets to | 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. | ||
This occurs awkward at first sight, but is done for the following reasons: | This occurs awkward at first sight, but is done for the following reasons: | ||
Zeile 37: | Zeile 35: | ||
* This way, mmmuxd doesn't need to be changed or restarted whenever a new media "adaptor" is connected to the daemon | * 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 | * 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 == | |||
There are 3 different packet types - these may be either one of '''inbound, outbound or internal''' packets. | |||
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 '''outbount packet'''. The third packet type - the '''internal''' packet - is used to exchange messages in between the connected clients. | |||
== Client Types == | |||
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. | |||
Both client types use the same library (mmmux lib) to handle connections. |
Version vom 12. November 2011, 12:18 Uhr
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.
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 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.
Migration from current Infrastructure
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.
Metainformation and modes of operation
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:
- version -- protocol version
- speed -- speed at which the packet was received (in bit/s)
- frequency -- frequency on which the packet was received (in Hz)
- medium: medium from which the packet was received (or is to be sent if "stick to mediun" flag is present)
- source ID
- ethernet: for client-to-client requests (i.e. requesting data from a connected proxy)
- canbus
- radio
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.
This occurs awkward at first sight, but is done for the following reasons:
- Clients may want to use multiple distinct media at the same time
- 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
There are 3 different packet types - these may be either one of inbound, outbound or internal packets.
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 outbount packet'. The third packet type - the internal packet - is used to exchange messages in between the connected clients.
Client Types
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.
Both client types use the same library (mmmux lib) to handle connections.