SoNIC - A lightweight network library Version 0.3b 17.09.08

[tr909]

Werds auch mal testen.

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 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 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 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 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 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 von HalloDu:

[OT]Irgendwie erinnert mich der Name an eine Videospielfigur [/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 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
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

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

[x] Du bist beratungsresistent.

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

[hamburcher]

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