Indy-Komponenten

[blablab]

Hallo!

Ich dachte immer, man kann die Indy-Komponenten mit den restlichen Komponenten die Delphi bereitstellt vergleichen. Aber kann es sein, dass die Indy-Komponenten um einiges schlechter sind?

Ich hab bis jetzt die Komponenten nur für Http, TCP und UDP verwendet. Aber ich hab damit schon relativ viel schlechte Erfahrungen gemacht.
Z.B bekommt der Server der TCP oder UDP Komponente ein Ereignis bei einer eintreffenden Nachricht, der Client nicht. Beim Client muss man dann selbst pollen und lustigerweise blockiert das dann die Anwendung und man braucht zusätzlich eine Anti-Freeze-Komponente...
Und zb bei der idHttP-Komponente ist mir aufgefallen, dass es bei Get() kein einheitliches TimeOut gibt. (Und selbst einstellen kann man das TimeOut dummerweise auch nicht...) Mal bricht er das Verbinden nach 5s ab, mal erst nach 20s. Und es ist bei mir auch schon vorgekommen, dass Get() überhaupt nicht mehr abgebrochen hat, so dass ich das Programm dann nach einer halben Stunde beenden musste.
Und außerdem brauchen die Komponenten zusätzlich noch sehr viel Speicherplatz, wobei mir das eigentlich egal wäre, würden sie wenigstens gescheit funktionieren...

Was ich eigentlich fragen wollte ist, ob ihr auch so schlechte Erfahrungen mit den Indy-Komponenten gemacht habt? Benutzt ihr oft diese Komponenten oder weicht ihr auf andere Lösungen aus? Ist das bei anderen Indy-Komponenten auch so?
Kurz: Was haltet ihr von den Indy-Komponenten?

Simon

[CCRDude]

Sag doch erstmal vorab, ob Du Dich auf Indy 9 oder Indy 10 beziehst?

Indy 9 finde ich teilweise auch ziemlich übel - ist nicht wirklich sauber, sprich beim Beenden eines Programmes, das Indy 9-Komponenten benutzt, wird beispielsweise eine TCriticalSection nicht korrekt freigegeben. Unter Vista macht das teilweise richtig Probleme.

Ich benutze inzwischen Synapse und/oder die Wininet-API, wobei ich neulich auch mal einen Blick auf Indy 10 geworfen habe und das besser als Indy 9 finde.

[Udontknow]

Hallo!

Bezüglich TCP: Der Server hat eben kein Ereignis für ankommende Daten. OnExecute ist nur die Routine, die vom für die Verbindung bereitgestellten Thread angestossen wird, es wird direkt beim Connect angestossen. Mit dem Empfang von Daten hat das Ereignis nichts zu tun, dafür musst du ja dort auch wieder Read /Readln etc. aufrufen. Da der Server eben auch immer einen neuen Thread für eine Verbindung kreiert, gibt es dort kein "Blocking" des VCL-Threads.

Wie sollte Indy denn deiner Meinung nach das beim Client realisieren? Soll bei jedem eintreffenden Byte ein Ereignis getriggert werden? ;-)

Im Client musst du eben das Einlesen von Daten selber managen. Schau dir doch mal die SimpleTCP-Komponenten von mir an, dort realisiere ich es so, daß in einem separaten Thread Daten gesammelt werden und erst bei "Vollständigkeit" (bei mir komplette Übertragung eines Streams) per Synchronize ein Event getriggert wird.

Cu,
Udontknow

[alzaimar]

Die ICS-Komponenten von Francois Piette (www.overbyte.be) sind auch ziemlich generisch. Dort fliegen dir die Events nur so um die Ohren.

Soweit ich das kapiert habe, sind die Indies auf Einfachheit und Usability ausgelegt, u.U. mit Einschränkungen (was bei so einer Prämisse nicht auszuschließen ist). Genau weiß ich das aber nicht.

[Meflin]

Was ich von den Indys halte?

Das beste, was du zu dem Preis bekommst. Und ob die kostenpflichtigen Alternativen so viel besser sind, wage ich zu bezweifeln. Denn die Indys sind insgesamt doch ziemlich gut! Ich persönlich kann deine schlechten Erfahrungen auch nicht teilen, habe selbst eigentlich nur gute gemacht ;)

[blablab]

@CCRDude: Ich weiß net so genau welche Version das ist. Da sie beim Delphi dabei war und ich nicht extra Indy 10 installiert habe behaupte ich mal dass ich mich auf Indy 9 beziehe.

Zitat:

Zitat von Udontknow

Wie sollte Indy denn deiner Meinung nach das beim Client realisieren? Soll bei jedem eintreffenden Byte ein Ereignis getriggert werden?

Ich versteh nicht ganz wieso ich bei jedem Byte n Ereignis bekommen sollte... Das ist doch beim Server au net so. Ich hätte es gerne so realisiert wie auch beim Server.
Oder findest du es etwa gut, jedesmal noch eine extra Anti-Freeze-Komponente zu benutzen?
Und ich glaub, wenn mans beim Server au selber triggern müsste, wärs mir auch relativ egal. Es sollte halt zumindest einheitlich sein und wenn möglich ohne zusätzliche Anti-Freeze-Komponente funktionieren.

@Meflin:
Da hast du natürlich recht, das Preis-Leistungs-Verhältnis ist natürlich perfekt!
Ich hab mich nur gewundert, dass ich bei den Indy-Komponenten auf so viele unschönheiten gestoßen bin, wo das bei den anderen Komponenten nirgens so ist.
Deshalb dachte ich mir, ich frag mal nach eurer Meinung...

[Udontknow]

Zitat:

Zitat von blablab

Zitat:

Zitat von Udontknow

Wie sollte Indy denn deiner Meinung nach das beim Client realisieren? Soll bei jedem eintreffenden Byte ein Ereignis getriggert werden?

Ich versteh nicht ganz wieso ich bei jedem Byte n Ereignis bekommen sollte... Das ist doch beim Server au net so. Ich hätte es gerne so realisiert wie auch beim Server.
Oder findest du es etwa gut, jedesmal noch eine extra Anti-Freeze-Komponente zu benutzen?

Ich hab´s bereits geschrieben: Der Server hat eben KEIN Ereignis für Datenempfang! Und genauso ist es ja auch mit dem Client. ;-)
Die Execute-Routine ist nur die Hauptsteuerungsroutine für den Thread, der für die TCP-Verbindung zuständig ist. Es wird durch den Verbindungsaufbau ausgelöst, und nicht durch Datenempfang!
Wie gesagt, ich lagere die clientseitigen Empfangsroutinen in einen separaten Thread aus und brauche deshalb auch nicht AntiFreeze.

Cu,
Udontknow

[blablab]

Ob ich jetzt n ereignis bekomm wenn er ne verbindung macht oder was auch immer, auf jeden Fall bekomm ich beim Server n Ereignis, wenn ich daten bekomme und beim Client nicht... Und meiner Meinung nach sollte das entwedr bei beiden gehn oder bei keinem. Wobei das ja nur ein Problem ist, das mich stört.
Dann interpretier ich das mal so, dass du mit den Indy-Komponenten vollkommen zufrieden bist und dir bis jetzt auch noch keine Unschönheiten aufgefallen sind, die dich stören.

Vielleicht bin ich ja auch wirklich der einzigste hier, der was gegen solche Dinge wie AntiFreeze-Komponenten hat und den es nervt, wenn man eine Komponente ins Formular tut und gleichzeitig die exe um 100kb größer wird und man 3-4 neue namen in der uses-klausel stehen hat...

[Meflin]

Zitat:

Zitat von blablab

gleichzeitig die exe um 100kb größer wird

Wen stört das? Traffic ist billig...

Zitat:

und man 3-4 neue namen in der uses-klausel stehen hat...

Wenn dich DAS stört, dann öffne die Indy-Units (Source ist ja dabei) und kopiere den Quelltext in deine Haupt-Unit :roll:

[blablab]

@Meflin:
Ne, eigentlich störn mich die 100KB, die wahrscheinlich net alle notwendig sind und wegen den vielen Dateien in der Uses-Klausel zustandekommen. Und ich frag mich auch, wie die 100KB zustandekommen nur zb für nen TCP-Server...

Aber probiers mal aus den Code in dein Projekt zu kopiern. Das wird schwierig, derade deswegen, weil du die vielen Dateien in der Uses-Klausel hast und die einzelnen Dateien wieder viel in der Uses-Klausel stehn haben...
Ich wär sogar interessiert an einem solchen Programm bei dem der Quelltext eines idHttp bzw idTCPServer kopiert ist. Ich wollte nämlich mal mit dem Debugger gucken, wieso er fürn Get() mal 5s und mal 20s TimeOut braucht. Aber leider funktioniert der Debugger in den TCP-Komponenten net...