Auf dieser Seite stelle ich kurz vor, was die sich gerade in der Entwicklung befindende Version 2.0 von IrCOMM2k an Fortschritt bringen kann. Hier werde ich zudem das Erreichen wichtiger Meilensteine bekanntgeben, sowie zu einem möglichen Alpha- und Beta-Test einladen. Ferner spinne ich ein paar Ideen weiter, die mir zu den Möglichkeiten der neuen Architektur von IrCOMM2k gekommen sind.

Der Plan

Mit einem Gespann aus zwei neuen Systemtreibern konnte ich mich bereits in den Datenstrom zwischen meinem IR-Adapter-Treiber und Microsofts IrDA-Protokolltreiber einschalten. Damit habe ich vollen Zugriff auf die IrDA-Rohdaten, die vom Adapter empfangen werden oder vom ihm gesendet werden sollen. Wenn ich nun den IrDA-Verkehr ständig beobachte, sollte es möglich sein, ankommende Anfragen an den virtuellen COM-Port bereits im Kernel an diesen weiterzuleiten. Ferner kann ich bei Bedarf auch selbst eine Verbindung initiieren, indem ich entsprechende Roh-Daten für den IR-Adapter erzeuge und direkt an ihn sende. Damit sind folgende Verbesserungen möglich:

• volle Unterstützung aller IrCOMM Funktionen, d.h. die Übermittlung aller (virtuellen) Statusleitungen zwischen den Teilnehmern

• Besonderheiten bestimmter Gegenstellen oder auch Anwendungsprogramme können berücksichtigt werden, so daß auch diese nun mit IrCOMM2k laufen (z.B. Psion-Handhelds)

• Verbesserung der Latenzzeit durch direktere Verbindung von IR-Adapter und virtuellem COM-Port. Das kann sich je nach Art des Datenverkehrs auch positiv auf den mittleren Durchsatz auswirken

• IR-Debug-Schnittstelle zum Mitzeichnen des Datenverkehr wird bessere Analyse von Problemen erlauben

Leider ist der Aufwand bis zu einer ersten voll funktionstüchtigen Version noch recht groß. Im Prinzip ist eine minimale Implementierung des IrDA-Protokolls erforderlich - und dieses Protokoll ist auch dann noch recht umfangreich...

Oder man nehme einen fertigen, sehr robusten und auch noch frei verfügbaren IrDA-Stack und baue ihn einfach in Windows ein. Aber woher bekommt man so etwas? Natürlich aus dem Linux-Kernel! Genau diesen Weg verfolge ich nun. Zunächst soll eine Konsolenanwendung entstehen, die einen seriellen IR-Adapter ansteuert. Wenn das funktioniert, erfolgt die Migration in den Windows-Treiber - womit Linux womöglich zum ersten Mal Einzug in das Heiligste von Windows hält: den System-Kernel!

Aktueller Fortschritt

04.01.2003: Der Treiberkern kommt nun dem angestrebten Funktionsumfang der Release schon sehr nahe: Microsofts IrDA und IrCOMM2k können jetzt parallel betrieben werden! Ein Forward-Treiber, der als Infrarotadapter installiert werden muss (einer für jeden physikalisch vorhandenen Adapter), leitet den Verkehr weiter, solange der virtuelle COM-Port geschlossen ist. Wird er geöffnet, übernimmt IrCOMM2k die Kommunikation wie bisher. Fehler beseitigt, der die Kommunikation mit bestimmten IR-Geräten gestört haben könnte (es gab Berichte über hängen gebliebene PSIONs). Weitere Speicherlecks in Linux-IrDA gesucht und gefunden (nobody is perfect). Das sollte nun die letzte Alpha-Version gewesen sein. Der nächte Milestone ist die Aktualisierung des Setup-Programms. Eventuell werde ich auch schon ein kleines Tool schreiben, um IR-Verbindungen zu visualisieren, die IrCOMM2k aufbaut. Das Ganze wird dann Beta1 heißen und die Phase einleiten, in der nur noch restliche Fehler behoben werden.

27.12.2002: Ein verspätetes Weihnachtsgeschenk: die Alpha3 ist da mit ein paar Fehlern weniger: Ursache der Abstürze mit "MULTIPLE_IRP_COMPLETE_REQUESTS"-Meldung behoben. Workaround für Probleme mit Hummingbird Exceed (betraf schon die 1.x-Versionen!). Programme, die ohne Timeout und ohne Flusskontrolle auf den COM-Port schreiben, wurden bislang dauerhaft blockiert, wenn keine IR-Verbindung aufgebaut wurde. Linux-Kern aktualisiert (2.4.20) und teilweise auf Speicherlecks untersucht (Patch für Linux selbst ist in Vorbereitung). IrDA-Protokoll meldet sich nun anderen Geräten gegenüber mit dem Systemnamen und nicht mehr nur mit "Linux-IrDA". Im nächsten Schritt (Alpha4) werde ich mich der Anbindung des Microsoft-IrDA-Stacks widmen, damit auch dessen Funktionen bei Bedarf wieder genutzt werden können. Mir kommt der Satz irgendwie bekannt vor?

15.12.2002: Mit der heute freigegebenen Alpha2 (siehe Download-Seite) sollten wieder ein paar Psion/Communicator-Nutzer mehr per Infrarot synchronisieren können! Vorabtests deuten jedenfalls daraufhin. Änderungen in dieser Version: Statusleitungen werden nun in beide Richtungen unterstützt. Bis zum Aufbau der IR-Verbindung gelten Eingangsleitungen als gesetzt (löst Psion-Problem). Vervollständigung der IOCTL-Funktionen des virtuellen COM-Ports. Fehler unter XP behoben, der bei manchen IR-Adaptern zum sofortigen Absturz führte. Fehler beseitigt, der zu Abbrüchen bei der Übertragung großer Datenmengen führte. Im nächsten Schritt (Alpha3) werde ich mich der Anbindung des Microsoft-IrDA-Stacks widmen, damit auch dessen Funktionen bei Bedarf wieder genutzt werden können.

01.12.2002: Hier ist sie nun, die lang versprochene Alpha-Version! Auf der Download-Seite finden sich die ausführbaren Dateien und natürlich auch die zugehörigen Quellcodes. Zur Installation bitte unbedingt die Hinweise in der zugehörigen Readme.txt lesen! Was bereits klappt (bei mir): Hotsync mit einem PalmOS-4.0-Gerät (schneller als mit eingebauter Infrarot-Unterstützung von Hotsync!), voller Zugriff auf ein S35i mit S25@once, ViSie, PEP2000 und Sx35CZ, insbesondere der Logo-Upload läuft im Gegensatz zu früher absolut problemlos. Was noch nicht klappt (laut einem Vorabtester): Synchronisation mit Psions. Ich bin aber sehr optimistisch, dank der umfangreichen eingebauten Diagnosemittel dieses Problem auch "aus der Ferne" früher oder später zu lösen. Was noch fehlt: einige IOCTL-Steuerbefehle des virtuellen COM-Ports (u.a. zum Setzen von Statusleitungen auf der Gegenseite), (Teil-)Parallelbetrieb des Microsoft-IrDA-Stacks zur Nutzung anderer IrDA-Dienste als IrCOMM, Setup-Programm, GUI zur Konfiguration und Diagnose uvm. Stichwort Rückmeldungen: Fehlerberichte bitte per Mail an mich. Entweder brauche ich eine genaue Beschreibung, wie ich den Fehler nachstellen kann, oder die zugehörige Ausgaben von irda2kdump.exe und Portmon. Was hingegen funktioniert (und früher vielleicht nicht ging), bitte ins Forum posten. Kleine Anekdote am Rande: Während der intensiven Arbeit mit dem verwendeten Linux-IrDA-Stack aus Kernel 2.4.19 trat ein Speicherleck in dessen Code zu Tage (nobody is perfect...). Prinzipiell war den Linux-Entwicklern das Problem schon bekannt, nicht aber die exakten Zeilen. Eine der Quellen dieses Problems, die für IrCOMM2k sehr kritisch war, konnte aufgedeckt und beseitigt werden. Ein Patch wird auch bald im Linux-2.5er-Kernel enthalten sein. Das ist Open-Source!

04.11.2002: Es ist fast geschafft: Der IrDA-Stack ist als Protokolltreiber implementiert und der virtuelle COM-Port wurde an diesen bereits angebunden. Heute gelang mir nun zum ersten Mal eine Datenübertragung aus einem Terminalprogramm über Infrarot zu meinem Handy - die Rückrichtung ist jedoch noch nicht ganz fertig (aber die Handy-Antwort erschien schon auf der Debug-Konsole!). Der Protokolltreiber nutzt direkt alle von Windows unterstützten IR-Adapter. Er verarbeitet entweder die Daten selbst oder leitet alles transparent zum Windows-IrDA-Treiber weiter. Ferner kann er mehrere Adapter ansteuern (getestet mit einem seriellen ACTiSYS IR220L+ und einem Tekram IRmate 410U, USB). Alles läuft bei mir sehr stabil, so daß ich zuversichtlich bin, bald eine erste Alpha-Version freigeben zu können. Noch zu tun ist folgendes: Datenempfang durch den COM-Port, Statusleitungen setzen und lesen, interne Flußkontrolle des virtuellen Ports. Sagen wir mal, 2 Wochen noch! PS: Der Psion-Test mit irdalnx war übrigens nicht erfolgreich. Danke an alle, die es probiert haben.

22.09.2002: Der Linux-IrDA-Stack läuft! IrCOMM ist integriert und das Programm so erweitert, daß es den virtuellen COM-Port ansteuern kann. Erste Tests mit Handy und Palm sind vielversprechend, allerdings macht sich immer noch die fehlende Verarbeitung der Statusleitungen bemerkbar. Diese wird erst in der endgültigen Version enthalten sein (einige grundlegende Änderung im COM-Port-Treiber sind dafür nötig). Alpha-Tester gesucht: Wer Lust hat, den aktuellen Stand einmal auszuprobieren, kann das Progamm downloaden und den Beschreibungen der Readme.txt folgen. Natürlich ist auch der Quellcode verfügbar. Insbesondere Psion-Besitzer, die zufällig auch über den passenden ACTiSYS-Dongle verfügen, seien aufgefordert!

08.09.2002: Portierung von ersten Teilen des Linux-IrDA-Stacks in eine Win32-Konsolenanwendung war erfolgreich! Ein serieller Dongle (ACTiSYS IR220L+) wird angesteuert, IrLAP, IrLMP und IAS läuft. Nur minimale Änderungen an den Linux-Sourcen waren nötig, das meiste fangen Header-Dateien ab, welche die Linux-Includes ersetzen. Hier ein Snapshot der Kommunikation zwischen der Anwendung und meinem S35i. Das Handy versucht, einen Telefonbucheintrag zu versenden (der entsprechende Dienst fehlt auf der Gegenseite - IAS-Abfrage scheitert). Nächste Schritte: TTP und IrCOMM portieren, IrCOMM dann an den virtuellen COM-Port anbinden. Damit könnte schon eine Unterstützung von PsiWin (PSION Sync-Software) erreicht werden, wenn auch beschränkt auf den ACTiSYS-Dongle.

23.07.2002: Proof of Concept ist gelungen. Datenverkehr zwischen IR-Adapter und IrDA-Protokoll konnte durch eigene Treiber geleitet werden, ohne die Funktion der IR-Schnittstelle einzuschränken. Ein einfacher IrDA-Traffic-Sniffer ist implementiert, der die Rohdaten in einer Konsole ausgibt (in Datei umlenkbar). Fest kodierte Namen für meinen IR-Adapter erlauben leider noch keine Installation auf anderen Systemen => eines der nächsten Ziele Ein paar Schnupperproben der Sniffer-Ausgabe ("<==": gesendet, "==>": empfangen): PEP2000 beim Handy-Logo-Senden (erfolglos), ebenso s25@once per IrCOMM2k (erfolglos) und schließlich s25@once per IR-Dateitransfer (erfolgreich).

Neue Möglichkeiten

Mit dem direkten Zugriff auf den IrDA-Verkehr besteht nun auch unter Windows 2000/XP die Möglichkeit, Analyse- und Monitor-Funktionen zu implementieren, wie man es vielleicht noch vom IR-Monitor unter 98 kennt (dieser stammt übrigens von HP und nicht von Microsoft...). Man könnte die Gegenstellen mit ihren angebotenen Diensten darstellen oder die Übertragungsrate und -qualität visualisieren.

Ferner wurden im Forum schon das eine oder andere Mal die Möglichkeit diskutiert, mehrere virtuelle COM-Port anzubieten, die dann bestimmten IR-Geräten (etwa über deren Namen) zugewiesen werden. Damit könnten mehrere Synchronisationsprogramme für unterschiedliche Handhelds etc. gleichzeitig laufen, ohne sich dabei zu behindern. Gebraucht wird also ein User-Frontend, das diese Zuordnung ermöglicht, die dann wiederum im IrCOMM2k-Kernel-Treiber umgesetzt würde.

Der Phantasie sind kaum Grenzen gesetzt, jedoch existieren sie in meiner Person. Ich kann mich immer noch nicht klonen und bin mit den Arbeiten an den Treibern schon gut beschäftigt. Wenn also jemand Lust hat, eine Windows-Anwendung mit den oben beschriebenen Funktionen zu programmieren - nur zu! Ein paar Vorkenntnisse über IrDA wären natürlich hilfreich, im wesentlichen ist aber Ethusiasmus gefragt. Über die Art der Schnittstelle zwischen den Kernel-Treibern und dem Monitor würden wir uns sicher einigen können.