SoNIC - A lightweight network library Version 0.3b 17.09.08

[inherited]

Hallo,

für ein größeres Projekt arbeite ich zurzeit an einer Netzwerkbibliothek, die es irgendwann mal mit Indy aufnehmen können soll.
Das ganze funktioniert auch schon soweit gut, wie gut das allerdings wirklich läuft sieht man natürlich nur im Praxistest.

Deswegen würde ich euch bitten, das Ganze einmal zu testen und mir eure "Erfahrungsberichte" mitzuteilen.

Eine detaillierte, englische Beschreibung befindet sich auf http://user.informatik.uni-goettinge...ka/?page_id=24

Features

• Schnell - SoNIC nutzt direkt die Windows Sockets (in Zukunft auch Linux-Kompatibel) und verzichtet auf unnötigen Overhead
• Klein - Die einzige notwendige Abhängigkeit ist WinSock - Nicht mehr und nicht weniger. Im moment arbeite ich auch daran, die WinSock von ihrer einzigen Abhängigkeit zu lösen, der Unit Windows. Ein kleines Konsolenprogramm mit SoNIC ist dann sagenhafte 15kb klein
• Einfach - Einfaches Arbeiten wie mit Indy: Connect, Send, Disconnect, fertig. Funktionen wie SendString, ReadByte, ... erleichtern die Arbeit
• Unabhängig - es wird keine VCL benötigt

Im Anhang befindet sich auch eine ChatDemo, die den TCPClient und Server im Einsatz zeigt.

Klassen
Zur Zeit zur Verfügung stehende Klassen sind:
TsoUDP: ein UDP-Socket, der an einen Port gebunden werden kann, oder einfach nur Daten durch die Gegend schleudern kann.
TsoTCPClient: ein TCP-Client, der sich zu einem Server verbinden kann.
TsoTCPServer: ein TCP-Server, der auf einem Port hockt und Daten empfängt, sowie die Clients verwaltet.


Was noch fehlt
Es fehlt noch ein TCP-Server (Siehe Changelog), außerdem sind die Send-/ReadStream-Methoden noch nicht implementiert. (Siehe Changelog) Das ganze soll noch Plattformunabhängig werden und auch etwas benutzerfreundlicher. Außerdem will ich die Windows aus den uses hauen.

Benutzung

UDP:
Man nehme ein TsoUDP-Objekt und erstelle es mit
  myUDP := TsoUDP.Create; Möchte man etwas verschicken, so muss man zunächst den Host und den Port setzen:

Delphi-Quellcode:

  myUDP.Host := 'mein.host.de';
  myUDP.Port := '42';

Und anschließend eine Send-Funktion seiner Wahl aufrufen.
Es gibt zur Zeit:

Delphi-Quellcode:

    procedure SendBuffer(var a; length: Integer);
    procedure SendByte(a: Byte);
    procedure SendWord(a: Word);
    procedure SendInteger(a: Integer);
    procedure SendCardinal(a: Cardinal);
    procedure SendChar(a: Char);
    procedure SendString(a: String);
    procedure SendLine(a: String); // ab Version 0.2
    procedure SendStream(a: TStream; length: Integer; bFromBeginning: Boolean = true); // ab Version 0.3

Also zum Beispiel:
  myUDP.SendByte(42); Zum Empfangen muss man zunächst den OnData-Callback setzen:

Delphi-Quellcode:

procedure TMyForm.OnData(sender: TsoSocket; afrom: TsoSender);
...
  myUDP.OnData := MyForm.OnData;

Der Sender enthält das sendende Objekt, in diesem Fall wird es nur myUDP sein. Damit kann man eine Callbackfunktion für mehrere Sockets verwenden. Das AFrom-Struct enthält IP und Port des Senders, damit man diese Unterscheiden kann.

Damit die Callback-Funktiona auch aufgerufen werden kann, muss regelmäßig
myUDP.CheckData; Das kann man entweder in einem Timer, oder besser noch in einem Thread erledigen.
Wird das OnData-Event aufgerufen, kann man mithilfe der Read-Methoden Daten lesen.
Momentan gibt es folgende Read-Methoden:

Delphi-Quellcode:

    procedure ReadBuffer(var a; length: Integer);
    function ReadByte: Byte;
    function ReadWord: Word;
    function ReadInteger: Integer;
    function ReadCardinal: Cardinal;
    function ReadChar: Char;
    function ReadString: String;
    function ReadLine: String; // ab Version 0.2
    procedure ReadStream(a: TStream; length: Integer; bFromBeginning: Boolean = true); // ab Version 0.3

Zum Beispiel:

Delphi-Quellcode:

procedure TForm1.SonicData(sender: TsoSocket; afrom: TsoSender);
var a: Byte;
begin
  a := myUDP.readByte;
  ShowMessage(IntToStr(a) + ' from '+ AFrom.IP);
end;

Um auf einem bestimmten Port auf eingehende Pakete zu Lauschen, ruft man einfach die Methode Listen auf. das bindet den UDP-Socket an einen Port und wenn man möchte, auch an eine bestimmte Adresse. Der Rest bleibt gleich
  myUDP.Listen(42); Bei TCP ändert sich nicht viel.
Das Erzeugen:

Delphi-Quellcode:

  myTCP := TsoTCPClient.Create;
  myTCP.Host := 'mein.host.com';
  myTCP.Port := 42;
  myTCP.Connect;

Connect ist blockierend und friert den Thread ein, bis entweder ein Timeout einsetzt oder eine Verbindung zustande gekommen ist.
OnData wird wieder gefeuert, wenn Daten ankommen (vorausgesetzt man ruft CheckData auf) und mithilfe der Send und Read-Methoden können Daten versendet werden
Disconnect beendet die Verbindung und mithilfe von .Connected kann geprüft werden, ob eine Verbindung besteht.

Ein TCP-Server (neu ab Version 0.2) wird folgendermaßen benutzt:
Zunächst wird ein Server erzeugt, der Port gesetzt und eventuell Callbackfunktionen zugewiesen. Die Property Host kann ebenfalls gesetzt werden, in dem Fall wird der Server an diese Adresse gebunden.

Delphi-Quellcode:

  SonicServer := TsoTCPServer.Create;
  SonicServer.Port := 42;
  SonicServer.OnData := MyData;
  SonicServer.OnConnect := MyConnect;
  SonicServer.OnError := MyError;

Neu ist hier das OnConnect, das aufgerufen wird, wenn eine neue Verbindung eingeht. Sie enthält eine var-Variable Accept, die, auf false gesetzt, den Verbindungsvorgang abblockt.
Um den Server zu aktivieren, muss die Property Active auf true gesetzt werden:
  SonicServer.Active := true; Sendet jetzt ein Client etwas, wieder vorausgesetzt CheckData wird regelmäßig aufgerufen, wird OnData aufgerufen.

Zu guter letzt noch zur Fehlerbehandlung. Bei sämtlichen Fehlern wird, sofern zugewiesen, das OnError-Event gefeuert.
procedure SonicServerError(sender: TsoBaseSocket; ErrorCode: Integer); ErrorCode enthält die Fehlernummer, die ausgewertet - zB mit SysErrorMessage angezeigt - werden kann.

Außerdem gibt's noch eine OnDisconnect-Funktion
So, viel Spaß beim Herumspielen

Changelog Version 0.3 16.09.2008

• - Unglaubliche Umstrukturierung des Codes
• + ReadStream/SendStream-Methoden implementiert
• - Keine Deadlocks mehr =D
• - Diverse gigantomanisch viele Bugfixes und Code-Verbesserungen, die ich garnicht mehr zusammen kriege

Changelog Version 0.2 08.09.2008

• + Neue Klasse TsoTCPServer. Zur Verwendung siehe oben.
• + Neue ReadLine/SendLine-Funktionen
• - Code ein wenig aufgeräumt, Neustrukturierung, ...
• - Ein paar Bugfixes

Todo:

• Plattformunabhängigkeit
• Proxy
• Möglichkeit, automatisch Threads zu nutzen
• Timeout einstellbar

[aladin60]

Mal zurück von den Grundsatzdiskussionen, Vielfalt ist Alles, daher sind in meinen Augen solche Vorhaben Spitze!

-bei UDP fehlt mir noch ein Broadcast oder muss einfach nur das Host:=''?
-sollte man nicht besser Varianten einsetzen, als die Typen-festen Routinen?

Broadcast braucht man oft zur einfachen Verständigung von Instanzen (im Netzwerk). Genau da hätte ich es auch superschlank.

Bernd.

[MSSSSM]

Wie wärs mit einer HTTP-Kompo, auch schnell und zuverlässig?

[3_of_8]

Hat er doch schon geschrieben: Er wirds nicht machen, aber man kann gerne Erweiterungsklassen dafür schreiben.

[MSSSSM]

*faul sei*

Die FUnktion MakeWord hat da so ein inline, kann ich das wegmachen? D7 scheint das nicht zu kennen

[sirius]

"inline" kannst du wegmachen. Das bedeutet nur, dass der Code nicht als Funktion aufgerufen wird, sondern jeweils an den Ort reinkopiert wird (beim compilieren). Das kann D7 nicht. Die Funktionalität bleibt identisch.

[inherited]

Morgen,
nachdem ich die ganze Bibliothek in das Projekt eingepflegt habe, dabei noch das ein oder andere (ok, es war verdammt viel) geändert, gefixt, umstrukturiert, neu geschrieben, verbessert, wieder gelöscht, nochmal neu geschrieben und es dann doch ganz anders gemacht habe, hier jetzt die erste SoNIC-Version, die ich als stabil bezeichnen würde! Sie läuft inzwischen wunderbar flockig in einem größeren Projekt
Mit Version 0.3 kommen u.a. auch die SendStream/ReadStream-Methoden dazu. Auch sollte es jetzt Delphi7-Kompatibel sein.

Mehr Infos wie immer im ersten Post. Leider ist die Webseite derzeit nicht erreichbar, weil das ansässige IFI gerade umzieht.

[inherited]

Da hatte sich noch ein kleiner Fehler im TCP-Disconnect eingeschlichen. Die Version 0.3b steht jetzt zur Verfügung

[inherited]

Ich habe im ersten Beitrag eine kleine Chat-Demo beigefügt, die den Umgang mit Client und Server verdeutlichen soll