Zu den Vorgaben der DFS gehörte, dass die Sammlung der Daten über Probes (spezielle Sonden an den Netzzugängen) erfolgen sollte. „Für Wartung und Troubleshooting hatten wir bereits Probes im Einsatz. Es wäre unökonomisch gewesen, sie nicht einzubeziehen“, erläutert Biegel. Bei Uni-X existierten bereits Softwaremodule für die Kommunikation mit Probes. Im Wesentlichen habe es sich daher um ein Standardprojekt mit kleinen Anpassungen gehandelt, urteilt Biegel. Insgesamt sei er sehr zufrieden mit dem Produkt.
Während der Testphase trat eine kleine, unvorhergesehene Schwierigkeit auf: Die Probes des Anbieters Netscout arbeiteten anfangs nicht richtig mit dem Open Informer zusammen, so dass es zunächst nicht möglich war, Daten an das weiterverarbeitende System zu liefern. Entwickler von Uni-X fanden heraus, dass die Schwierigkeit bei der Abfrage der Schnittstellen lag.
In die Kategorie „kleine Herausforderungen“ fällt auch das Ausfiltern doppelt übertragener Pakete. Da die DFS ein hohes Maß an Verfügbarkeit sicherstellen muss, sind die Leitungen zu den größeren Standorten redundant ausgelegt. Trotzdem dürfen doppelt übertragene Pakete nicht zweimal abgerechnet werden.
Nach Angaben des Herstellers ist es einfach, die Pakete zu vergleichen und Duplikate herauszufiltern, wenn die Datensätze sehr genau beschrieben sind. Sind dagegen nur eine Quell- und eine Zieladresse sowie ein paar Byte Länge bekannt, so sind zusätzliche Redundanzfilter erforderlich, die das Netzdesign berücksichtigen. Dass das Ausfiltern redundanter Pakete funktioniert, bestätigt auch der Anwender.
Weichen die gemessenen Datenmengen auf den redundanten Pfaden voneinander ab, so zählt der Open Informer normalerweise den höheren Wert. Das wollte Biegel jedoch nicht zulassen – mit der Begründung, innerhalb des WAN könnten ja Daten verworfen werden. In diesem Fall kämen am Ende der Leitung weniger Daten an, als abgeschickt wurden, und der jeweilige Kunde müsse mehr bezahlen, als wirklich übertragen worden sei. Auf Wunsch des Anwenders nahm die Uni-X Software AG die entsprechende Änderung vor, so dass nun der minimale Wert in die Abrechnung eingeht.
Die bei weitem größte Herausforderung stellte jedoch die anwendungsabhängige Abrechnung im LAN dar. Im lokalen Netz sollten die Kosten nicht nur dem Endnutzer zugewiesen werden, der sie verursacht hat, sondern auch einem Dienst. „Wir wollten wissen, ob das E-Mail-, Internet- oder SAP-Verkehr war“, skizziert Biegel die Beweggründe. „Das ging nur über sehr umfangreiche Regelwerke.“ Der Grund: Der Open Informer öffnet die einzelnen Datenpakete nicht. Dann aber liefern die Probes prinzipiell nur die IP-Adressen von Quelle und Ziel, die Zeitstempel und Angaben, wie viel Bytes übertragen worden sind.
Den Bezug zu einem Dienst definieren nun Regeln (Filter): Falls Daten zu einer IP-Adresse fließen, die einem SAP-Server gehört, handelt es sich beispielsweise um SAP-Verkehr. Wenn sie von dort kommen, war es die Antwort des SAP-Servers. „Die Regelwerke waren der Hauptgrund, warum wir uns für den Open Informer entschieden haben. Dessen Regeln waren so, wie wir sie brauchten“, resümiert Biegel.