|
Indy-Komponenten
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 |
Re: Indy-Komponenten
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. |
Re: Indy-Komponenten
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 |
Re: Indy-Komponenten
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. |
Re: Indy-Komponenten
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 ;) |
Re: Indy-Komponenten
@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:
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... |
Re: Indy-Komponenten
Zitat:
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 |
Re: Indy-Komponenten
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... |
Re: Indy-Komponenten
Zitat:
Zitat:
|
Re: Indy-Komponenten
@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... |
Re: Indy-Komponenten
Zitat:
Im Gegenzug dazu empfinde ich Synapse deutlich handlicher mit recht gutem Support und einer übersichtlichen Dokumentation. Allerdings bleibt es auch bei Synapse dabei, das man sich selbst um Empfang und Senden kümmern muss, will sagen auch hier wird kein Ereignis ausgelöst, wenn Daten empfangen werden... ... aber das ganze in einen "Endlos"-Thread gepackt und Prüfung ob Daten anliegen funzt wunderbar (und die eigene Anwendung wird auch nicht "blockiert"). |
Re: Indy-Komponenten
@OG Karotte:
Das hört sich ja ganz interessant an. Werd mir das Synapse mal anschaun... Eine Frage hätte ich noch, da dir der Platzverbrauch von den Indy's ja au nicht so gefällt. Zitat:
|
Re: Indy-Komponenten
Zitat:
Arghhh... Zum dritten Mal: Das OnExecute-Event des TCPServers ist kein Datenempfangsevent! Der einzige Grund, warum beim Server es dieses Event gibt, und beim CLient nicht, ist, daß der Server mehrere Verbindungen auf einmal verwalten muss. Es ist einfach nur da, um dem Programmierer die Möglichkeit zu geben, Code in Abhängigkeit der Verbindung (Parameter AContext bzw. AThread) zu definieren, der dann ausgeführt werden muss. Innerhalb der Execute-Routine (also innerhalb des Verbindungsthreads) wird doch aber genauso "geblockt", wenn du ein Readln o.ä. aufrufst... Bis dann, Andreas |
Re: Indy-Komponenten
Hallo,
Zitat:
Gruß Jörg |
Re: Indy-Komponenten
@Udontknow:
Tut mir leid wenn ich dich nerv... Ok, lassen wir das. Ich glaub ich hab verstanden was du meinst. |
Re: Indy-Komponenten
Zitat:
hier (die Website) oder hier als direkter Download (ca. 800 kb).Und als ergänzende Info kann ich diese PDF empfehlen (Ist allerdings (immer noch) in einem sehr frühen Stadium :( ). Trotzdem kann man das eine oder andere dort nachschlagen / vertiefen.@blablab: Zitat:
mal kostet der Traffic (ich nehme mal an es wird der Download gemeint) nichts (Fulltimeflat), mal ein wenig (Flatrate nach Traffic) und mal 'n bisschen mehr (Modem / ISDN (Na ja, es sei denn es ist eine SAT-Verbindung, dann sind es ca. 9 Euronen die Minute, aber das ist eher die Aussnahme)). Aber bei den heutzutage üblichen Proggrössen fallen diese 100k auch nicht mehr so in's Gewicht... |
Re: Indy-Komponenten
Zitat:
Zitat:
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 15:06 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz