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

Delphi-Quellcode:

  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:

Delphi-Quellcode:

  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

Delphi-Quellcode:

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

Delphi-Quellcode:

  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:

Delphi-Quellcode:

  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.

Delphi-Quellcode:

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 :hi:

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 :gruebel:[/OT]

[Hador]

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

Zitat:

Zitat von HalloDu

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

Stimmt. Aber an welche nur :gruebel:

[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:

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

Delphi-Quellcode:

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 :gruebel:
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 :zwinker: :cheers:

[DeddyH]

Tatsache, ich bin es nicht :mrgreen: :cheers:

[tr909]

Werds auch mal testen.

Zitat:

Zitat von sirius

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.

Grund könnte wohl folgendes sein. Ist aber nur eine Vermutung ;)

Zitat:

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

Gruß
tr909

[alzaimar]

Ich kann auch nur dringend empfehlen, eine der beiden Standard-Bibliotheken zu verwenden.
Die Indy-Bibliothek ist doch nun wirklich ausgereift. Gut, Asynchron arbeitet sie nicht, aber wer das möchte, greift sich eben die ICS-Suite von Francois Piette, der daran nun auch schon bald 10 Jahre arbeitet.

[Assertor]

Hallo inherited,

ein Lob für Deinen Ansatz, wobei ich gerade bei der vorhandenen Auswahl (Indy, ICS und Co) denke, es wäre zu viel Arbeit auf Dauer für Dich alleine. Es gibt bei Torry etliche Komponenten/Units, die ähnliches versuchen.

Zitat:

Zitat von Relicted

(ich persönlich halte nicht so das meiste von den indys...)

Das verstehe ich nicht. Jetzt muß ich nachdem ich immer wieder Indy-bashing sehe, was erklären:

Das größte Problem liegt an der "Klassen-Orgie" innerhalb der Indys. Viele haben einfach damit ein Problem, sich da einmal einzulesen. Aber ich habe mich auch in die Indys einarbeiten können...

Zitat:

Zitat von Sherlock

und ich hoffe du verzichtest auf diese seltsame Antifreeze Geschichte.

Ja, diese Komponente gibt es auch nur für "Programmierer", die mit Threads nicht umgehen können. Wie oft wird hier die Frage gestellt, warum bei (blocking Sockets &) Indy die Anwendung freezt. Dann wird schnell mal Application.ProcessMessages in den Raum geworfen und alles ist gut... So geht es natürlich nicht.

Aber die Komponente jetzt in TIdTryToAntiFreezeMyAppForDummies umzubenennen wäre auch keine Lösung.

Zitat:

Zitat von sirius

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.

Eben.

Denke an den Funktionsumfang von ICS (100 .pas Units) oder Indy (jetzt 352 .pas Units in Core/System/Protocols). Da sind ja nicht nur Units für Delphi/FPC, Sockets für Windows und Linux, sondern auch IPv4/IPv6 Unterstützung, Hash und Enconding/Decoding, Typumwandlungen und Prüfungen, RFC Standard-Umsetzungen, Server/Client-Abstraktionen, FTP List-Parser für die verschienen Gegenstellen (bei Indy allein ~ 40 Dateien), SSL Protokolle, SSH für kommerzielle Komponenten etc.pp.

Du brauchst auch -sehr- viel Hintergrundwissen in Bezug auf die Eigenheiten der unterschiedlichen Implementationen von "Standards", zu denen Du eine Verbindung herstellst.

Zusätzlich kommt der administrative Aufwand und die Kompatibilität zu älteren (und neueren) Delphi Versionen und Windows Versionen hinzu.

Arno Garrels, der am ICS mit(ge)arbeitet (hat?) schrieb einmal, daß einige ICS Klassen, wie z.B. TSmtpClient/TFtpClient endlose if-then-else Spagetti-Code enthalten. Bei den Indys sind es halt die vielen verkapselten Klassen...

Grob gesagt: ICS = protokollnah, Indy = Verkapselte Klassen für hohe Abstraktion.

Das manche Programmierer, gerade Einsteiger, bei mangelndem Leitfaden hier überfordert sind, trifft sicherlich zu. Aber das macht den Code nicht schlecht, defekt oder was sonst auch immer in den einzelnen Threads vorgeworfen wird.

Genau so wie es Threads gibt mit "wie Programmiere ich einen Treiber in Delphi" oder "wie Programmiere ich ein Betriebssystem in Delphi" - am besten innerhalb von einem Tag - gibt es bei den Indys auch fehlende Grundkentnisse beim Programmierer, die zu Problemen führen.

Ich habe mich seit ich hier bin für die Indys erwärmen können. ICS ist sicherlich nicht schlecht, eben anders und für andere Problemstellungen. Der Vorteil für mich war, daß die Indys gleich bei Delphi dabei waren und so einem Ausprobieren nichts im Wege stand.

Gruß Assertor

Just my 2 Euros (too long for 2 ct)

[Relicted]

Zitat:

Zitat von Assertor

Das verstehe ich nicht. Jetzt muß ich nachdem ich immer wieder Indy-bashing sehe, was erklären:

Das soll kein Indy-bashing sein. Ich arbeite nicht viel mit Sockets bzw. den Indys. Ich gebe zu in dem Gebiet ein ziemliches Greenhorn zu sein. Ich habe kein Problem mit Klassen ohne Ende, nur bin ich nicht wirklich gewillt für ein einfaches String hin und her geschubse zwischen 2 Rechnern je 2 Komponenten (Senden, Empfangen) auf meine Form zu klatschen und dann eher umständlich mit diesen Komponenten zu arbeiten.
Für solche Anwendungen sind die Indys wohl oversized. Und daher auch meine (mehr oder minder) Abneigung zu den Indys. Was mir persönlich fehlt ist eine Komponente die ich auf meine 2 Forms haue, der ich sagen kann "Connect('1.2.3.4')" dann "Send('mein text')" und bei der anderen Anwendung klappert ein "OnReceive(SenderIP, Text)" rein und ich kann wieder mit "Send" antworten. Mehr müsste solch eine Komponente (für mich) nicht tun.
Bisher hatte ich bis auf Telnet keine wirkliche Anwendung für ein "echtes" Protokoll. Ich glaube was einfach extrem nervig bei den Indys ist, ist dass man hier und da nen Beispiel findet aber man dieses nie verwenden kann weil man immer die falsche Version hat :?
Eine Indy-Wiki mit Beispielen, Erklärungen und Problembehandlungen wäre das was man zur "Rufverbesserung" der Indys bräuchte. Und darin muss dann auch eine Trennung zwischen den 9ern und 10ern.

Also bitte nicht falsch auffassen aber das sind (leider) meine Erfahrungen mit den Indys.

Gruß
Reli

[alzaimar]

Zitat:

Zitat von Relicted

Was mir persönlich fehlt ist eine Komponente die ich auf meine 2 Forms haue, der ich sagen kann "Connect('1.2.3.4')" dann "Send('mein text')" und bei der anderen Anwendung klappert ein "OnReceive(SenderIP, Text)" rein und ich kann wieder mit "Send" antworten. Mehr müsste solch eine Komponente (für mich) nicht tun.

Genau so funktioniert Indy: TIdHttp und TIdTCPServer.
Genau für Noobs wie dich (und mich) sind die Indys ja auch gemacht. Wenn man keine Ahnung von TCP und dem ganzen Schmuh hat und eine einfache Remote-Funktionalität benötigt, dann sind die Indy's eben genau das Richtige. Ich hab keinen blassen Schimmer von dem Zeugs, aber mit den Indys komme ich klar. Genau wie Du will ich eine einfache TCP-Funktionalität, wo ein Client einem Server was schickt und der antwortet irgendwie.

Mit den ICS geht das auch und viel performanter, aber man muss sich mit ('Igitt') Events und ('Huch!') Statusänderungen rumschlagen. Oh, und einen Thread muss man programmieren.

Nimm die Indys (sag deinem Scheff aber nix davon), kapsle deren Funktionalität und präsentiere in 5 Monaten (in denen Du gar nix machen musst) deine Wrapper-Komponenten als deine Erfindung... (Hauptsache Scheff kommt nicht dahinter)

[inherited]

Hallo,

ich bin erstmal überrascht wie unglaublich viel Rückmeldung in so kurzer Zeit gekommen ist. Ich versuche mal alle Klarheiten zu beseitigen.

Zitat:

Zitat von HalloDu

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

Ich bin schrecklich kreativ in meinen Namensgebungen("Ding", "OnlineDelphi"...).
Es soll für etwas schnelles stehen, ich mag Igel, NIC hat was mit Netzwerk zu tun -> SoNIC, fertig.

Zitat:

Zitat von sirius

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.

Richtig, es soll eben kein Indy-Klon werden. Man soll es aber ruhigen Gewissens als Ersatz in Erwägung ziehen können. Ich persönlich habe nichts gegen die Indys, nur dummerweise kommt es bei denen, wenn ich die Benutze, manchmal zu seltsamen Effekten die ich mir nicht erklären kann, außerdem weiß ich nicht genau was bezüglich Threads und Co. unter der Haube passiert. Deswegen bevorzuge ich, vor allem wenn das in eigenen Threads laufen soll, etwas, was ich genau kenne oder mir zur Not anschauen kann, ohne 325 Units durchzuschauen.
Auch möchte ich auf die Implementierung der abstrakteren Protokolle verzichten, wenn jemand Lust hat, kann er aber gerne eine Erweiterungsunit schreiben, die die enthält.

Zitat:

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.

tr909 hat genau recht, das soll Plattformunabhängig werden, deshalb muss die raus oder zumindest nur bedingt mitkompiliert werden.

Zitat:

Zitat:

Damit die Callback-Funktion auch aufgerufen werden kann, muss regelmäßig

Delphi-Quellcode:

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.

Naja, Messages empfange ich nur, wenn ich ein grafisches Control habe, das ganze wird unter Linux auch nicht ganz einfach. Vielleicht stelle ich irgendwann einen überladenen Konstruktor bereit, der ein Owner mitkriegt und das alternativ über Messages macht. Aber erstmal wird es das nicht geben.

Bevor ich aber groß was erweitere, muss ich erstmal wissen ob das soweit läuft.

[inherited]

Ich habe eine neue Version hochgeladen. Neben Fehlerkorrekturen steht jetzt auch eine TCP-Server-Komponente zur Verfügung. Changelog und neue Version im ersten Post :firejump: :firejump:

[alzaimar]

[x] Du bist beratungsresistent.
[x] Du bist Enthusiast
[x] Du lässt dich nicht runterkriegen

[inherited]

Es gibt jetzt auch eine (noch ziemlich rudimentäre) Website: http://user.informatik.uni-goettinge...ka/?page_id=24

Zitat:

Zitat von alzaimar

[x] Du bist beratungsresistent.

Nur wenn mich die beratende Instanz nicht von ihrem Standpunkt überzeugen kann :mrgreen:

[hamburcher]

Zitat:

Zitat von alzaimar

[x] Du bist beratungsresistent.
[x] Du bist Enthusiast
[x] Du lässt dich nicht runterkriegen

[x] Selten so über ein "x" in eckigen Klammern gelacht!

Alzeimar ist
[ ] doof
[x] hat mich zum Lachen gebracht

Danke alzaimar!

Sorry für offtopic :mrgreen:

[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 :firejump:
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 :firejump:

[inherited]

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