SocketAdapter - Protokoll - Wie aufbauen?

[Zacherl]

Hey,

ich habe ein nettes Protokoll geschrieben mit dem sich Daten wunderbar über die normalen TCustomWinSockets versenden und empfangen lassen, ohne, dass die Pakete falsch getrennt oder zusammengesetzt werden. Auch eine on-the-fly Kompression und Verschlüsselung ist möglich.

Bisher muss der Programmierer für jedes Socket ein TBufferData Record anlegen und im OnClientRead Ereigniss "HandleSocketData(BufferData, Socket)" aufrufen. Wenn ein vollständiges Paket angekommen ist wird eine Callback Funktion für die ein Pointer im BufferData Record bereitssteht aufgerufen.

Das ganze kommt mir nun doch etwas kompliziert vor. Ich überlege nun aber, ob ich alle Funktionen in eine Klasse packen soll, oder ob ich in der Unit eine globale Liste erstelle, den Parameter der HandleData Funktion auf das Socket beschränke und das Erstellen / Ermitteln des dazugehörigen Records intern verwalte. Der Programmierer soll eigentlich nämlich auch keinen Zugriff auf die einzelnen Elemente erhalten.
Eine Klasse wäre dafür ganz nett, wenn ich mal so auf die private Deklarationen schiele, anderseits habe ich das Problem, dass ich einmal eine Klasse für die TCustomWinSockets machen will und die selbe Klasse nochmal für ein selbstdefiniertes TClientSocket Object. Bisher habe ich mir mit überladenen Funktionen geholfen. Geht dies auch in Klassen? Der Klasse würde das Socket im Constructor übergeben. Die Verwaltung der Klassen muss der Programmierer zwar weiterhin selbst vornehmen, aber die Datenverarbeitung würde sich auf ein Klasse.HandleData beschränken, wobei natürlich vom Programmierer darauf geachtet werden muss, welche Klasse zu welchem Socket gehört. Auch einfacher als die Callback Funktionen wären die klassichen OnBLABLABLA Methoden.

Welche Vorgehensweise würdet ihr empfehlen?

Gruß

[Sko]

In der Delphi-Library hat Narses ein interessantes Tutorial geschrieben das dir vielleicht helfen kann: [klick].

[Apollonius]

Die klassische Methode wäre eine neue Komponente, die einen Socket in einem privaten Feld hat. Die Klasse verwaltet somit alles, für den Benutzer sieht es so ähnlich aus, als würde er die Sockets direkt verwenden. Es entfällt außerdem die Zuweisung von Events, die sowieso immer gleich sein sollen.

[Zacherl]

@Sko: Das Protokoll ist nicht das Problem, das habe ich ja schon :)
@Apollonius: Daran habe ich auch schon gedacht, allerdings möchte ich kein TClientSocket oder TServerSocket kapseln, sondern beim TClientSocket das eine CustomWinSocket und beim TServerSocket ALLE CustomWinSockets die pro Verbindung erstellt werden. Die Daten dieser Verbindungen sollen daher auch getrennt abgearbeitet werden, wobei es möglich sein soll verschiedene Events / Callbacks zu vergeben.

[BenjaminH]

Zitat:

Zitat von Zacherl

beim TClientSocket das eine CustomWinSocket und beim TServerSocket ALLE CustomWinSockets

Das würde durch einen Class Helper(spätestens ab D2k6 möglich) drin sein. Damit wird das für alle TCustomWinSockets in deinem Programm gelten.

[Zacherl]

Klingt interessant. Gibt es dafür eine Demo?

[BenjaminH]

Ich hab nur ein Anwendungsbeispiel im Kopf.
Du willst der Klasse TPanel eine Funktion hinzufügen, um z.B. es ein und ausklappen zu können.

Delphi-Quellcode:

TFader = class helper for TPanel
  published
    procedure FadeIn;
    procedure FadeOut;
end;

procedure TFader.FadeIn;
Begin

End;

Ab da hat jedes Panel diese Prozeduren, die dann direkt über

Delphi-Quellcode:

TPanel.FadeIn;

aufgerufen werden können.

[Zacherl]

Perfekt :) Danke dir .. werde ich direkt mal testen.

[shmia]

Um ein ähnliches Problem habe ich mir auch schon Gedanken gemacht.
Angenommen man möchte EMails per SMTP versenden.
Sobald der Socket offen ist, benötigt man ja nur noch Lese- und Schreibfunktionen.
Welcher Art von Socket oder ob man über einen Proxyserver geht oder die Daten verschlüsselt ist ja mal egal.
Man könnte sich auch folgendes Szenarios vorstellen:

Code:

SMTP-Protokoll <---> [HTTP Packer/Entpacker] <---> [TCP Socket] <-> Netzwerk
SMTP-Protokoll <---> [Secure Socket Layer] <--> [Serielle Schnittstelle]

An den Stellen, die mit "<--->" gekennzeichnet sind, besteht eine bidirektionale Schreib-/Leseverbindung.
Ich nenne dies mal eine "Pipeline".
Die Pipeline könne man über folgendes Interface implementieren:

Delphi-Quellcode:

  IPipeline = interface;
  IPipelineCallback = interface(IUnknown)
     procedure DataAvailable(Sender:IPipeline);
  end;

  IPipeline = interface(IUnknown)
      function Read(var Buffer; Count: Longint): Longint;
      function Write(const Buffer; Count: Longint): Longint;
      function GetReadSize: Integer;   // Anzahl der Bytes, die mit Read gelesen werden können
      procedure SetCallBack(cb:IPipelineCallback);
  end;

Damit der Benutzer von IPipeline nicht ständig fragen muss, ob Daten zum Lesen vorhanden ist, gibt es das Interface IPipelineCallback.
Mit diesem Ansatz könnte man nun Blöcke hintereinander schalten.

Code:

SMTP-Protokoll <---> [StreamCompressor/Dekompressor] <---> TCP Socket

Der StreamCompressor/Dekompressor würde also einerseits das Interface IPipeline implementieren, damit es vom
SMTP-Protokoll benützt wird,
andererseits benützt es ein IPipeline-Interface, das von TCP Socket implementiert wird.
Auf diese Weise entsteht ein Baukastensystem, deren Teile man zu Ketten zusammenschalten kann.