... it is the responsability of the originator
to establish standards acceptable to its subscribers.
(IPTC Recommended Message Format, 1995, TEC 7901 R5, p.9, fn.2)

 

IPTC Dämon

 

Das publizistische Gewerbe – die sogenannten Medien – lebt von Nachrichten; Neuigkeiten, die es seinen Kunden verkaufen kann. Wesentliche Quellen solcher Nachrichten sind neben den je eigenen KorrepondentInnen die verschiedenen Nachrichten-Agenturen: Wie  XYZ  meldete .... Solche Agentur-Meldungen können auf unterschiedlichen Wegen zu ihren AbnehmerInnen gelangen. Ein häufig anzutreffender führt über verschiedene Zwischenschritte (z.B. Satelliten, Empfänger, Konverter usw.) schließlich in eine serielle Schnittstelle, wie sie auch bei PCs seit über zwei Jahrzehnten üblich sind.

Hier, an der seriellen Schnittstelle eines PCs, beginnt nun die Arbeit des iptcd: Er liest - kurzgefaßt – die hereinkommenden Daten ein, analysiert ihre formale Struktur, bereitet sie in bestimmter Weise auf und spielt sie schließlich mittels SQL in eine Datenbank ein oder speichert sie in Text-Dateien auf der Festplatte.

Mithin kann das Programm bei Zeitungen und Zeitschriften ebenso eingesetzt werden wie bei Rundfunk und Fernsehen oder anderen AbonnentInnen der erwähnten Nachrichten-Agenturen. (Tatsächlich ist es ursprünglich genau für diesen Zweck entwickelt worden.) Es benötigt dazu keine Zeit- und Kosten-aufwendigen Server-Installationen, sondern ist mit einem schlichten GNU/Linux Rechner zufrieden. Der MySQL-Server kann auf der gleichen Maschine laufen oder auch irgendwo anders im Netz, der iptcd kann mithilfe einer einfachen Text-Datei entsprechend konfiguriert werden; dies gilt genauso bspw. für Anzahl und Namen der auszulesenden seriellen Schnittstellen, wie auch alle anderen Programm-Optionen. – Weitere Informationen zur Funktionsweise des iptcd sind in der Quell-Kode Dokumentation zu finden.

Die Datenbank

Ein erster Schritt besteht in der Entwicklung einer Datenbank, die auf einer separaten Seite genauer beschrieben wird. Ein Teil dieser Arbeit war die Analyse der Eingangs-Daten (der von den Agenturen gesendeten IPTC Nachrichten), ein anderer Teil die Definition der Ausgangs-Daten (die zu erzeugenden Daten-Sätze). Beides ist Voraussetzung, um hernach den iptcd Dämonen zu entwerfen.

Programmierung

Der IPTC-Dämon ist als multi-threaded application realisiert. Dies bedeutet, daß mehrere Ausführungs-Fäden (sog. threads) quasi parallel abgearbeitet werden. Einige dieser Anweisungs-Fäden behandeln die auf jeweils einer seriellen Schnittstelle eintreffenden Nachrichten. Diese werden zunächst eingelesen und in ihre Attribute zerlegt. Die so aufbereiteten Daten werden dann an ein oder mehrere andere Anweisungs-Fäden weitergegeben, die sich um die Auslieferung kümmern; das heißt sie schreiben die Nachricht beispielsweise in eine Text-Datei oder leiten sie an einen Datenbank-Server weiter. All dies kann konfiguriert werden und bedarf keiner weiteren Programm-Änderungen.

 Abb.: vereinfachtes Software Modell
vereinfachtes Software Modell

Im linken (rötlichen) Bereich der Abbildung sind die wesentlichen Tätigkeiten des "Programm-Laders" dargestellt. Im mittleren (grünlichen) Bereich sind die wichtigsten Aktionen des Haupt-Fadens der Arbeit (main thread) aufgeführt. Und im rechten (bläulichen) Bereich der Graphik schließlich sind Arbeiten der Lese- und Schreib-Arbeiter (worker threads) angedeutet.

Selbstverständlich kann diese Darstellung nur die grobe Funktionsweise des Dämons wiedergeben (schließlich lassen sich weit über 30.000 Zeilen Quell-Kode nicht mit ein paar Symbolen abbilden). Doch alle im Rahmen dieses Projektes entwickelten C++ Klassen sind ausführlich dokumentiert und können hier online gelesen werden.

Mittels einer Konfigurations-Datei kann der iptcd Dämon gegenwärtig so eingestellt werden, daß er bis zu acht serielle Schnittstellen parallel ausliest (wahlweise mit oder ohne Protokollieren in eine Capture-Datei), die eingegangenen Nachrichten in bis zu vier verschiedene Datenbanken schreibt, sowie nebenher noch Sicherungs-Dateien sowohl erstellt als auch bei Bedarf/Vorhandensein einliest. Mithin kann insgesamt ein Dutzend Arbeiter praktisch gleichzeitig aktiv sein. Die Arbeitsspeicher-Belastung liegt typischerweise zwischen 2 und 3 MB und, wenn nichts zu tun ist, unter 1 MB. Für das Einlesen von knapp 51.000 Nachrichten, die via Netzwerk (nicht lokal) in zwei verschiedene Datenbanken geschrieben wurden, hat der iptcd Dämon rund 157 Minuten Rechenzeit benötigt (an realer Zeit vergingen unterdessen 13:05 Stunden, mithin weniger als eine Sekunde Realzeit pro komplett verarbeiteter Nachricht). Weitere Einzelheiten, insbesondere zur Konfiguration, können in der (englisch-sprachigen) Programm Dokumentation nachgelesen werden.

Ursprünglich  - übrigens -  war die Struktur ein wenig anders: Die (Datei- und Port-) Leser starteten für jede eingegangene/gelesene Nachricht einen (oder mehrere, je nach Konfiguration) Schreiber, die dann die Daten auf die Platte oder in die Datenbank schrieben. Leider zeigte sich bei Streß-Tests, daß insbesondere schmallbrüstige Rechner (etwa der 100Mhz Klasse) dadurch leicht überlastet werden konnten. Daher gingen dann mehrere tausend Zeilen Programm-Kode den Weg alles Vergänglichen, und das jetzt verwendete Queue-Modell wurde entwickelt. Hier werden die gelesenen Nachrichten nun von den Lesern in eine (bzw. mehrere, für jeden Schreiber eine) Warteliste (Queue) gestellt, von wo sie dann durch die Schreiber abgeholt und ihrer Bestimmung zugeführt werden. Zwar mag dieses Verfahren ein wenig langsamer sein (jedenfalls für den Rechner, nicht für Menschen, die ohnehin nur maximal im Minuten-Takt nach neuen Nachrichten schauen). Doch besteht sein Charme darin, daß es – auf's Ganze gesehen – weniger Last erzeugt und überdies auch noch sicherer ist.

[... more to come eventually ...]
ChangeLog
NEWS