Generelle Frage zu den Indy-Komponenten

[Der schöne Günther]

Hallo-

Eigentlich bin ich ein großer Freund von Abstraktionen, beispielsweise der Delphi-Aufsatz TThread zu reinen WinAPI-Methoden.

Aber mit den Indy-Komponenten komme ich ehrlich gesagt überhaupt nicht zurecht. Die blöden Teile werfen bei jeder erdenklichen Gelegenheit Exceptions: Ich habe eine kleine Library im Einsatz, welche auch Indy-Komponenten verwendet. Blöd nur, wenn diese im Destruktor ein

Delphi-Quellcode:

DisconnectClient()

von Indy ausführt, dieses aber eine Exception wirft und die nicht gefangen wird. Ich scheine also nicht der einzige zu sein, der da nicht wirklich durchblickt zumal ich entweder zu dumm bin, oder das auch in der (wenn überhaupt vorhandenen) Quelltext-Doku nicht kenntlich gemacht wird.

Ich brauche keine konkrete Hilfe, auf lange Sicht ist mir der ganze Kram jetzt schon so unsympathisch dass ich es wahrscheinlich wieder manuell über WinSockets machen werde. Ich möchte nur wissen, ob es mir nur so vorkommt, oder die Indy-Dinger wirklich wunderbar gerne bei jeder Gelegenheit Exceptions werfen - Und wenn ja, ob das überhaupt gut gelöst ist. Die zwingen einen ja gerade dazu, Exceptions zu essen...

[baumina]

Also ich habe mich schon vor ein paar Jahren gegen Indy entschieden, weil es mir auch nur Probleme gemacht hat. Indy 9 hatte was was ich brauchte, das in Indy 10 nicht ging und Indy 10 hatte was was ich brauchte, das wiederrum in Indy 9 nicht ging. Durch ständiges Switchen von Indy 9 auf 10 und wieder zurück war zum Schluss das komplette Chaos, so dass ich, bevor ich komplett verzweifelte, das ganze anders gelöst hatte.

Allerdings fällt mir hier auf, dass es wohl doch viele gibt, die Indy verwenden, oder fällt es mir hier nur auf, dass so viele Probleme damit haben, wer weiß...

[taveuni]

Deshalb benutzen wir schon lange die meiner Meinung nach robusten ICS oder manchmal Synapse.

[DataCool]

@Der schöne Günther:
Wo liegt den konkret Dein Problem mit den Indys ?!

Klar die Indys schmeissen viele Exceptions, das ich aber auch so gewollt!
Exceptions zum Fehlerhandling! Wenn man das weiß & berücksichtigt, lässt sich mit Indy gut arbeiten.
Ich habe die Indys in einigen Projekten zur TCP/IP Kommunikation genutzt und würde es wieder tun.

Greetz Data


P.S.: ICS & Synapse funktionieren aber auch

[Hansa]

Also mich verwundert die Frage schon sehr. :shock: Ich bin immer noch etwas erstaunt darüber, dass es einwandfrei gelingt mit 10 Zeilen eine email zu empfangen oder einen FTP-Server zu bestücken.

Wo kommen denn die Exceptions überhaupt her ? Zeig mal eine. Vielleicht liegt der Fehler ja auch hier :

Zitat:

Zitat von Der schöne Günther (Beitrag 1215358)

Eigentlich bin ich ein großer Freund von Abstraktionen, beispielsweise der Delphi-Aufsatz TThread zu reinen WinAPI-Methoden.

...

[Der schöne Günther]

Zitat:

Zitat von DataCool (Beitrag 1215365)

Exceptions zum Fehlerhandling! Wenn man das weiß & berücksichtigt, lässt sich mit Indy gut arbeiten.

Wie gesagt, ich habe kein konkretes Problem - Es geht darum, dass ich leider nicht riechen kann, wo unter Umständen Exceptions geworfen werden (siehe auch ein anderes Thema von mir). Die Indy-Teile zwingen mich geradezu, alles mögliche in try-Blöcke zu legen und die Exceptions zu essen - Dem Benutzer irgendwelche Messageboxen mit "Socket Error #10053!!" auf den Bildschirm zu knallen ist keine Art.

Ich will nichts schlechtreden, vielleicht habe ich auch einfach nur eine tolle Dokumentation übersehen. Der Quelltext von idTCPConnection beispielsweise besteht zu 25% aus einer Changelog und mindestens 10% von Kommentaren zu Fehlern aus Vorgängerversionen. Auch wenn die Methodennamen halbwegs selbstredend sind - Was drinnen nun konkret vorgeht hätten ein paar Kommentare gerne näher erläutern können.

Mein Punkt war nur, dass ich anscheinend nicht der einzige bin, der solche Probleme hat. Ich wollte nur wissen, ob das von der Indy-Philosophie wirklich so gewollt ist. Ganz gemütlich plauschen.

[DataCool]

@Der schöne Günther:
Jap, das ist so gewollt! Wie Hansa auch schon sagt, so viele Exceptions sind es gar nicht mehr. FTP, Email und andere Protokolle laufen komplett ohne Exceptions ab(es sei den es kann nicht verbunden werden oder es fehlen Rechte).
Wenn Du eine eigene Kommunikation mit IdTcpServer und IdTcpClient aufbaust, gibt es auch nur 4 Stellen wo Du was abfangen must:
- Connect
- Disconnect
- Alle Schreiboperationen
- Alle Leseoperationen

Ob Du diese dann ignorierst oder weiter verarbeitest bleibt allein Dir überlassen.
Viele der Exceptions erscheinen auch nur innerhalb der IDE !!!

Hoffe das hilft weiter,

Greetz Data

[mjustin]

Zitat:

Zitat von DataCool (Beitrag 1215375)

Wenn Du eine eigene Kommunikation mit IdTcpServer und IdTcpClient aufbaust, gibt es auch nur 4 Stellen wo Du was abfangen must

Wobei man beim TIdTCPServer natürlich vermeiden sollte, die Exceptions abzufangen, die Indy mitbekommen muss um eine Connection zu schliessen. Siehe zum Beispiel http://www.delphipraxis.net/139748-t...isconnect.html

[DataCool]

Ganz genau, eine der wenigen bösen Stolperfallen !! Gute Anmerkung

[sh17]

Eine Komponente zu verwenden, die im Destroy ein Disconnect mit potentieller Exception verwendet ist aber auch nicht gerade das gelbe vom Ei, da würde ich eher hier ansetzen.

[greenmile]

Finally ist ne tolle Erfindung

[Der schöne Günther]

Thema nur quergelesen oder auch verstanden? :hi:

[greenmile]

Ja, ich habe aber den Sinn nicht so ganz verstanden. Exceptions sind mehr als Sinnvoll, die kannst Du aber einfach abfangen, dafür gibt es Try...Except und schon tauchen die Exceptions nicht mehr auf. Übel sind nur eingebaute Messageboxen, irgendeine Indy Version hatte mal eingebaute Hinweise, bis ich darauf gekommen bin. Insgesamt mag ich persönlich ICS lieber.

[Der schöne Günther]

Finde ich ja auch. Exceptions sind für mich beinnahe die beste Erfindung seit zweilagigen Klopapier. Dass bei einem

Delphi-Quellcode:

Disconnect()

eine Exception geworfen wird wenn nicht alles klappt kann ich noch ansatzweise verstehen.

Aber ich sehe nirgendwo in der Indy-Doku, dass ich hier eine Exception zu erwarten habe. Wenn ich für mich selbst etwas bastele, ist es ok, eine Exception ganz nach oben bis zum Benutzer durchzureichen, vielleicht kann ich spontan mit der Meldung auch etwas anfangen. Aber um die ganze Indy-Geschichte ordentlich verpackt einzusetzen bin ich ja reihenweise am Exceptions essen.

Fazit: Ich bin entweder zu dumm, richtig zu sehen, was ich wann zu erwarten habe, oder es wird einfach nicht deutlich.

[greenmile]

Ich habe kaum bis noch nie eine Doku gelesen, die so detailiert die Vorgehensweise beschreibt. Deshalb kaufe ich, wenn möglich, auch immer mit Source, dann kann ich selbst nachschauen wie manches gelöst ist und was wie passiert/passieren könnte. Ich hatte allerdings schon einige Komponenten bei denen ich lieber nicht hätte nachschauen sollen; so ein Goto im Source macht einem doch Angst ;)

[Codehunter]

Die Indy-Macher haben das Thema Exception eben zum Designprinzip gemacht. Es gibt ja die beliebte ClosedGracefully-Exception, die praktisch im HTTP-Normalbetrieb ständig ausgelöst wird. Da steht dann auch im Indy-Code an der betreffenden Stelle, man möge sich doch bitte jegliche Support-Anfragen dazu verkneifen. Andernfalls solle man geteert und gefedert werden.

An sich ist gegen diese Art der Verwendung von Exceptions ja nichts einzuwenden. Allerdings programmiert kaum jemand anderes so. Ich habe irgendwann die finale 9er Version genommen und komplett von Exception auf Eventhandler umprogrammiert weil mir das Ganze zu umständlich war. Exceptions lassen sich eben schlecht mit RAD vereinbaren, vorallem wenn sie den Normalzustand signalisieren.

Allerdings war ich mit der rein eventbasierten Indy-Version auch nicht sooo zufrieden. Sie haben den Vorteil, dass schon ziemlich viele Protokolle implementiert sind, dass die Serverkomponenten von Haus aus Threads unterstützen und dass die Doku recht umfangreich ist. Der Nachteil bei Indy ist eben leider die Komplexität sowie hier und da verschiedene kleinere Bugs und Unrundigkeiten.

Ich habe allerdings nicht genug mit Netzwerkprogrammierung zu tun, dass ein Umstieg auf ein anderes System wie ICS sich für mich gelohnt hätte.

[sx2008]

Also ich finde der Hauptschwachpunkt bei Indy ist die Klassenhierarchie.
Fast alle TCP-Protokolle (FTP, HTTP, SMTP, ...) sind von TIdTcpClient abgeleitet, was nicht richtig ist.

Die Klassen, die diese Protokolle implementieren dürften nicht abgeleitet sein, sondern müssten ein bidirektionales Streamobjekt benützen.

Sobald eine TCP-Verbindung aufgebaut ist, hat sie nur noch 3 Funktionen: senden, empfangen und schliesen.
Eine geöffnete serielle Schnittstelle hat rein logisch betrachtet genau die gleichen Funktionen.
Wäre Indy besser aufgebaut, dann könnte man z.B. Ketten von Komponenten bilden:

Code:

IdSMTP <--> IdEncyptDecrypt <--> IdMultiplexer <--> IdTCPSocket
IdTelnet <--> IdEncyptDecrypt <--^

In dem Beispiel werden 2 Protokolle verschlüsselt über eine einzige TCP-Verbindung geführt.
Anstelle von TCP könnte man genausogut Bluetooth, Firewire oder Named Pipes verwenden.

Auf jeden Fall sollten der Datentransport und das Protokoll streng voneinander getrennt sein.
Statt Vererbung müsste Indy die Delegation als Prinzip verwenden.

[sh17]

@sx2008 da hast Du Recht, das ist der Schwachpunkt im der Design der Indys - welche Alternative macht es richtig?

[mjustin]

Zitat:

Zitat von sx2008 (Beitrag 1215423)

In dem Beispiel werden 2 Protokolle verschlüsselt über eine einzige TCP-Verbindung geführt.

Wozu soll das gut sein? Welcher Mailserver kann zwischen den Mails, die er empfängt, auch noch Telnet Sitzungen bedienen (auf dem gleichen Socket)?

[sh17]

nein, er meint, da IdTelnet von TCP erbt, könnte man den Kanal von Telnet nicht einfach mal gegen einen anderen austauschen (Telnet z.B. über Names Pipes). Würde in dem Beispiel zwar keinen Sinn machen, theoretisch schon.

[mjustin]

Zitat:

Zitat von sh17 (Beitrag 1215427)

nein, er meint, da IdTelnet von TCP erbt, könnte man den Kanal von Telnet nicht einfach mal gegen einen anderen austauschen (Telnet z.B. über Names Pipes). Würde in dem Beispiel zwar keinen Sinn machen, theoretisch schon.

Dann verstehe ich das Beispieldiagramm nicht - der Multiplexer scheint beide Protokolle in einen einzigen Stream zu verbinden.

[sx2008]

Zitat:

Zitat von mjustin (Beitrag 1215425)

Zitat:

Zitat von sx2008 (Beitrag 1215423)

In dem Beispiel werden 2 Protokolle verschlüsselt über eine einzige TCP-Verbindung geführt.

Wozu soll das gut sein? Welcher Mailserver kann zwischen den Mails, die er empfängt, auch noch Telnet Sitzungen bedienen (auf dem gleichen Socket)?

Das war nur ein Beispiel der Möglichkeiten.
Auf der Serverseite müsste natürlich ein IdDemultiplexer eingesetzt werden.
Auf jeden Fall kann man mit diesem Konzept Datenströme verschlüsseln, komprimieren, zusammenfassen, tuneln, priorisieren,...

Zitat:

Zitat von sh17 (Beitrag 1215424)

@sx2008 da hast Du Recht, das ist der Schwachpunkt im der Design der Indys - welche Alternative macht es richtig?

Mir ist keine bekannt. Ich glaube alle anderen Komponentensammlungen haben das gleiche Problem.

[Morphie]

Ich halte das nicht für ein Designfehler.
Ein Protokoll der ISO-Schichten 5-7 ist doch normalerweise genau definiert.

HTTP läuft z.B. normalerweise über TCP, standardmäßig auf Port 80. Also ist es ein Nachfahre von TCP.
TFTP läuft normalerweise über UDP und hört auf Port 69. Ist also ein Nachfahre von UDP.

Wenn man Indy so aufbauen würde, dass man alle möglichen Protokolle aus dem unteren ISO-Modell und die Verschlüsselungen mischen / tauschen würde, wäre die Definition der einzelnen Protokolle doch irgendwie sinnlos...

Ich finde die Klassenhierarchie eigentlich ganz anständig so.

[sx2008]

Zitat:

Zitat von Morphie (Beitrag 1215436)

HTTP läuft z.B. normalerweise über TCP, standardmäßig auf Port 80. Also ist es ein Nachfahre von TCP.
TFTP läuft normalerweise über UDP und hört auf Port 69. Ist also ein Nachfahre von UDP.

HTTP ist etwas völlig Anderes als TCP.
HTTP benützt TCP als Transportmedium, aber es ist nicht eine Art von TCP.
Vererbung wurde hier falsch angewendet.
Das Gleiche gilt auch für TFTP und UDP.
Jeder Programmierer kennt bestimmt das OSI 7-Schichten Modell.
Zwischen diesen Schichten existiert keine Vererbung sondern jede Schicht benützt die vorherige Schicht als Grundlage.
Das Wort "benützen" ist hier entscheidend, denn es ist der Hinweis, dass hier keine Vererbung vorliegt.
TCP benützt das Internet Protokoll (IP). IP benützt Ethernet.
IP kann aber auch aber auch auf ISO 802.11 (WLAN) aufsetzen.

Tiger und Löwe sind spezialisierte Arten der allgemeineren Klasse "Raubkatze".

Delphi-Quellcode:

TRaubkatze = class;
TTiger = class(tRaubkatze)
TLoewe = class(TRaubkatze)

Ein Löwe "ist" eine Raubkatze; es liegt hier also eine richtige Vererbung vor.
Diese Beziehung gibt es bei HTTP ind TCP nicht.

[TiGü]

Zitat:

Zitat von sx2008 (Beitrag 1215442)

HTTP ist etwas völlig Anderes als TCP.
HTTP benützt TCP als Transportmedium, aber es ist nicht eine Art von TCP.
Vererbung wurde hier falsch angewendet.

Anstatt Vererbung wäre also eine Komposition eher angebracht?!

Zitat:

Zitat von sx2008 (Beitrag 1215442)

Zwischen diesen Schichten existiert keine Vererbung sondern jede Schicht benützt die vorherige Schicht als Grundlage.
Das Wort "benützen" ist hier entscheidend, denn es ist der Hinweis, dass hier keine Vererbung vorliegt.
TCP benützt das Internet Protokoll (IP). IP benützt Ethernet.

"Benützt" wurde hier falsch angewendet.

Abgesehen davon, dass es für alle deutsch Sprechenden nördlich von Heidelberg etwas schräg aussieht, meint "benützt" in den südlichen Dialekten eher antiquarisch, aus zweiter Hand, gebraucht, getragen oder secondhand.
Richtig wäre hier das Wort benutzt oder verwendet!

[bernhard_LA]

mit Demos zum Thema INDY und TCP Client Server kann ich helfen :

http://sourceforge.net/projects/indy10clieservr/


auch der E Mail client funktioniert ohne Probleme

http://sourceforge.net/projects/simpleemail/

( musss den aktuellen Source noch hochladen :roll: )


Die Doku zu INDY finde ich eher mau ... die Komponenten spielen aber bei mir ohne Probleme

[sh17]

Zitat:

Zitat von bernhard_LA (Beitrag 1215503)

( musss den aktuellen Source noch hochladen :roll: )

Ja, bitte.