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

[HalloDu]

Werde ich mir in den nächsten Tagen sicher mal ansehen, könnt ich auch in der Delphi-AG in meiner Schule verwenden, mal sehen. Sieht auf jeden Fall interessant aus und ich hoffe du arbeitest weiter daran, denn ein TCP Server wär schon schön.

[OT]Irgendwie erinnert mich der Name an eine Videospielfigur [/OT]

[Hador]

Ich werde das ganze auch mal in meinem nächsten Projekt testen.

Zitat von HalloDu:

[OT]Irgendwie erinnert mich der Name an eine Videospielfigur [/OT]

Stimmt. Aber an welche nur

[Relicted]

Endlich mal jemand der sich mal an eine schöne Version der Indys traut! (ich persönlich halte nicht so das meiste von den indys...)
Ich hatte auch mal überlegt mich an sowas ran zu machen. Aber irgendwie kam ich da bisher nie zu.
Ich werd das ganze gleich mal testen. Interessant fände ich wenn der TCP Client auch direkt als Server fungiert. Ich finde es irgendwie immer deppert 2 Komponenten für eigentlich eine Funktion (kommunikation zwischen 2 Rechnern) zu benutzen.

Gruß
Reli

[sirius]

Zitat von inherited:

für ein größeres Projekt arbeite ich zurzeit an einer Netzwerkbibliothek, die es irgendwann mal mit Indy aufnehmen sollen kann.

Ui, sich mit Indy zu messen, dürfte nicht so einfach sein. Außerdem bekommst du dann auch wieder so eine riesen große Bibliothek, was du, so vermute ich, gerade eben vermeiden wolltest.

Zitat:

von ihrer einzigen Abhängigkeit zu lösen, der Unit Windows.

Die Unit Windows stört doch nicht. Keine Variablen drin, kein initialization oder finalization-Abschnitt. Wo ist da das Problem? Es dürfte IMHO 0 Byte ausmachen, die Unit reinzunehmen (und keine Funktionen zu verwenden). Ausserdem befürchte ich, dass kein Programm ohne die Unit Windows wirklich arbeiten kann.

Zitat:

Damit die Callback-Funktion auch aufgerufen werden kann, muss regelmäßig
myUDP.CheckData; Das kann man entweder in einem Timer, oder besser noch in einem Thread erledigen.

Ob das ein Gewinn ist? Für einen Timer, wie für einen Thread brauch ich doch wieder die Unit Windows (welche du oben rausschmeißen wolltest). Da kannst du auch gleich ein Event oder eine Message der Sockets verwenden.


PS: Eine kleine UDP-Socket-Kompo hatte ich auch mal irgendwo hier in der DP
Edit: Voilà.

[Sherlock]

Welche Ereignisse soll es denn geben? Die SendGeschichten sind ja Brot und Butter, das Alleinstellungsmerkmal sind die Ereignisse, und ich hoffe du verzichtest auf diese seltsame Antifreeze Geschichte. Orientier Dich mal lieber nicht an den Indys, sondern an den WSocket-Komponenten von F. Piette. Die sind wirklich schlank und funktional.

Aber das ist wohl am Ende Geschmackssache. Und Hauptsache Du hast Spaß dabei und es bringt Dir was.

Sherlock

[Relicted]

Sherlock wo gibtsn die Kompos? Mag mich auch mal anschauen

[DeddyH]

http://www.overbyte.be, da nach ICS schauen.

[Relicted]

Du bist zwar nicht Sherlock aber danke trotzdem

[DeddyH]

Tatsache, ich bin es nicht