Verteilte Rechenkapazität durch »Remote Procedure Calls«
RPC-Middleware für Embedded Systeme
Fortsetzung des Artikels von Teil 3
Eingeschränkte Referenzen
Die unterschiedlichen Adress- und Speicherräume der verschiedenen Systeme verhindern das einfache Implementieren einer »Call by Reference«-Funktion. Nutzt eine Funktion Referenzen, ist es für die jeweilige Gegenstelle in der Regel unmöglich zu sagen, worauf die Referenz jeweils zeigt. Die Referenzen können beim Client eine andere Bedeutung haben als beim Server. Daher wurde bei der Implementierung der RPC-Middleware bewusst die Einschränkung getroffen, nur »Call by Value«-Funktionen zu nutzen. Genauso verhält es sich beim Rückgabewert. Arrays und andere Referenzen in Funktionsaufrufen ließen sich dennoch realisieren, indem die Referenzen aufgelöst und die dahinter stehenden Werte durch »Call by Value« übertragen werden. Auf der Serverseite muss das wiederum verarbeitet werden, und die Werte müssen in die jeweiligen Speicherstellen geschrieben werden.
Um das Scheduling, also den jeweiligen Zeitbedarf der RPC-Middleware-Schichten, muss sich der Entwickler dennoch kümmern. Um den üblichen Programmablauf nicht zu stören, sind die Schichten passiv und besitzen einen eigenen Handler, der regelmäßig aufgerufen werden muss, damit die Schichten die Anfragen bearbeiten. Dabei ist die Frequenz der Handleraufrufe für jeden Anwendungsfall zu definieren. Zum Beispiel sind bei Anwendungen, die LEDs schalten, sehr schnelle Antwortzeiten verlangt. Deswegen sollten dort nur sehr wenige Millisekunden zwischen zwei Handleraufrufen vergehen, damit die Verzögerung nicht auffällt. Dagegen sind Anwendungen beispielsweise im Bereich Heimautomation nicht ganz so kritisch und ermöglichen längere Zeiten zwischen zwei Aufrufen. Für die Ausführung einer Funktion kommt eine synchrone Kommunikation zur Anwendung. Das bedeutet, dass der Client nach der Anfrage auf eine Antwort wartet und erst danach weiterarbeitet. Im ungünstigsten Fall kann die Wartezeit des Clients auf die Antwort also zwei Scheduling-Perioden (Empfangen beim Server und danach beim Client) plus die Signallaufzeit und die Ausführungszeit der Funktion betragen. Dagegen wird der Server nur für die Laufzeit des Handlers und der auszuführenden Funktion unterbrochen.
Aufgrund der einfachen Implementierung gibt es einige Einschränkungen. So verfügt das Kommunikationsprotokoll nicht über Adressierung, vorerst ist also nur ein Client pro Server möglich. Weiterhin ist das Protokoll nicht durch Checksummen oder andere kryptografische Mechanismen abgesichert. Zum momentanen Zeitpunkt vertraut der Server seinem Client und führt keine Überprüfung durch, ob die Anfrage korrekt ist und der Client berechtigt ist, die aufgerufene Funktion auszuführen. Der Funktionsumfang lässt sich erweitern und kann zum Teil mit Hardwareunterstützung in einigen Mikrocontrollern realisiert werden. Damit ist eine gute Grundlage geschaffen, um den steigenden Kommunikations- und Rechenaufwand zu bewältigen.
Über den Autor:
Phillip Gesien hat bei Mixed Mode das Forschungsprojekt SIBASE und darin Embedded Security als Schwerpunkt.
Jobangebote+ passend zum Thema
- RPC-Middleware für Embedded Systeme
- RPC auf Embedded Systemen nutzen
- Zentrale Funktionen
- Eingeschränkte Referenzen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Industrie 4.0
Legosteine mit Webtechniken sortieren
Mikroprozessor-Entwicklungstools
Neues Analysewerkzeug für Hardware/Software-Debugging
Keynote-Speaker Tyson Tuttle
embedded world Conference 2015
Embedded-Betriebssysteme
VDC sieht Wind River als Marktführer
i.MX6-Module
Yocto-Unterstützung für SMARC-Module
Echtzeit-Betriebssystem
VxWorks 7: Wind River hat aufgeräumt
Internet der Dinge
Virtualisierung, Echtzeit, Sicherheit – kein Widerspruch
