Moin,
Ich habe nun in Gwen den letzten noch fehlenden Part - den IPC Code - auf den
neuen Netzwerk-Code umgestellt. Das laeuft somit inzwischen auch mit dem
bisher einzigen Client/Server des IPC-Codes: Libchipcard2.
Neuer Code fuer Interprocess Communication (IPC)
=========================================
Der alte IPC-Code war festgelegt darauf, ueber HTTP gefahren zu werden.
In Libchipcard2 wird auch weiterhin HTTP verwendet, aber das ist nun nicht
mehr Vorraussetzung. Der neue Code kann IPC grundsaetzlich ueber jede Art von
GWEN_NetLayer betreiben bleibt aber weitgehend Source-kompatibel zum alten
Code (bis auf das Handling von Verbindungen).
Dafuer habe ich nun einen neuen NetLayer hinzugefuegt, der die Arbeit mit
Paket-ortientierten Protokollen stark vereinfacht: GWEN_NetLayerPackets (kann
auch zu anderen Zwecken ausser IPC verwendet werden).
Dieser NetLayer kann nun ausgehende Pakete in eine Warteschlange einreihen und
nacheinander versenden, und genauso reiht er empfangene Pakete in eine andere
Warteschlange ein.
So braucht beispielsweise der IPC-Code nur noch die Kommandos in einen Puffer
schreiben, daraus ein GWEN_NL_PACKET zu erstellen (zwei Aufrufe) und dieses
Paket in die Warteschlange stellen.
Das praktische am neuen NetLayer ist, dass er nicht *nur* ueber
Paket-orientierte Protokolle laeuft, sondern grundsaetzlich ueber alle
GWEN_NetLayer laufen kann.
GWEN_NetLayer in Paket-orientierten Protokollen
========================================
Der generelle Ablauf beim Versenden von Daten ueber einen NetLayer ist dieser:
- GWEN_NetLayer_BeginOutPacket()
- GWEN_NetLayer_Write() [solange Daten zu senden sind]
- GWEN_NetLayer_EndOutPacket()
Im GWEN_NetLayerHttp wird beispielsweise beim ersten Aufruf die Kommando-Zeile
erzeugt (z.B. "GET / HTTP/1.1") sowie die Header ("Content-Length: 123" etc).
Diese werden dann in den darunterliegenden GWEN_NetLayer (meist
GWEN_NetLayerSocket oder Ssl) geschrieben. Sobald die Kommandozeile und der
Header geschrieben sind, werden die Daten, die ueber GWEN_NetLayer_Write()
uebergeben werden, hinterhergesendet.
Bei GWEN_NetLayerEndOutPacket() wird dann lediglich der Puffer geflushed sowie
alles fuer das naechste Paket vorbereitet.
Diese Vorgehensweise hat grosse Vorteile: Man muss nur noch einmal zu Beginn
ein NetLayer-spezifisches Setup machen (beispielsweise die Zieladresse fuer
eine Verbindung angeben, bei HTTP eventuell ein paar Header vorbesetzen), und
ab da ist der Ablauf beim Versenden eines Paketes fuer jeden NetLayer gleich.
Nur dadurch ist es moeglich, dass bisher alle NetLayer beliebig miteinander
stapelbar sind, ohne dass ein NetLayer sich mit dem jeweils darunterliegenden
auskennen muss.
GWEN_NetLayer in nicht-Paket-orientierten Protokollen
============================================
Was aber passiert bei nicht-Paket-orientierten Protokollen?
In diesem Fall sind die (virtuellen) Funktionen GWEN_NetLayer_BeginOutPacket()
und EndOutPacket() nicht gesetzt und geben stattdessen einen speziellen
Fehlercode zurueck, der besagt, dass diese Funktion nicht unterstuetzt wird
(GWEN_ERROR_UNSUPPORTED).
An diesem Fehlercode erkennt der Aufrufer - meist der drueberliegende NetLayer
- dass es sich *nicht* um einen Netzwerkfehler handelt und ignoriert diese
Meldung (setzt also seine Arbeit einfach fort).
Der Trick ist also: So ziemlich jeder GWEN_NetLayer (ausser Socket und Ssl)
verhaelt sich so, als ob sich unter ihm ein Paket-orientierter NetLayer
befaende. Ist das mal nicht der Fall, macht das auch nichts, weil in dem Fall
ja die Daten einfach so roh, wie sie bei GWEN_NetLayer_Write() uebergeben
werden, geschrieben werden koennen.
Synchrone vs asynchrone Netzwerk-Funktionen
======================================
Mit seinen vergleichsweise wenigen Funktionen aber dennoch grossen
Flexibilitaet ist daher der neue GWEN_NetLayer-Code deutlich dem alten Ansatz
von frueheren Gwen-Version ueberlegen.
Der neue Code ist dabei immer noch vollstaendig asynchron angelegt (was fuer
Single-Thread-Server wie Libchipcard2 notwendig ist), hat aber zusaetzlich
synchrone Funktionen, die von Clients gerne verwendet werden.
Diese synchronen Funktionen (zu erkennen am _Wait() am Ende des
Funktionsnamens) muessen aber nicht von jedem einzelnen NetLayer
implementiert werden, sondern werden von der Basisklasse zur Verfuegung
gestellt.
Das vereinfacht das Erstellen von neuen NetLayern sehr, denn diese muessen nur
eine Handvoll Funktionen implementieren, bieten aber dennoch einen grossen
Leistungsumfang.
Gruss
Martin
--
"Things are only impossible until they're not"
AqBanking - http://www.aquamaniac.de/aqbanking/
LibChipcard - http://www.libchipcard.de/
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Aqbanking-devel mailing list
Aqbanking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
