Tristan - Fr 19.05.06 19:51
Titel: Indy Komponente gesucht (mehrere Clients)

---

Guten Abend,

ich wollte euch fragen, ob ihr mir andere Komponenten als TClientssocket und TServersocket empfehlen könnt. War es nicht so, dass Borland die Komponenten rausgeschmissen hat weil sie veraltet waren?

Ich habe das Problem, dass sich mehrere Clients an einem Server mit ihrem Computernamen anmelden müssen und dann auf Befehle vom Server warten müssen. Bis jetzt habe ich das so gemacht, dass der Client ständig prüft ob der Server online ist und wenn ja seinen String sendet.
Wenn nun aber alle Clients online sind und der Server als letztes aktiv wird kommt es zu einer Masse von Verbindungsversuchen. Das Resultat: nicht alle Clients können sich anmelden bzw. es kommt zu irgendwelchen Überläufen.

Die gesuchte Komponente müsste also mehrere Verbindungen aufnehmen können - möglichst in Echtzeit.

Danke im Vorraus!

alias5000 - So 21.05.06 13:33

---

Benutze doch TidTCPClient/Server
Die Socketkomponenten benutzen auch nur TCP

Gruß alias5000

Tristan - So 21.05.06 14:12

---

Bei Client und serversocket konnte man einen String ja mit Socket.sendtext senden sowie mit receiveText empfangen.

Wie stellt man das denn am besten mit TidTCPClient/Server an? In anderen Posts war da immer vom writeln/readln die Rede?!

matze - So 21.05.06 20:08

---

schau mal bei den OpenSource Units hier im Forum nach den SimpleTCP Komponenten. Das sind Wrapper für Indy, mit denen man sehr komfortabel arbeiten kann !

Narses - So 21.05.06 23:34

---

Moin!

Tristan hat folgendes geschrieben:

War es nicht so, dass Borland die Komponenten rausgeschmissen hat weil sie veraltet waren?

Naja, sie sind schon veraltet, was die API und das Wrapper-Konzept angeht, aber es ist eben immernoch "nur" ein Wrapper für die WSA, die dadrunter liegt, Indy etc. machen da auch nix anderes, es geht nur um die API, die sich dir als Programmierer bietet.

Bei einem konkreten Vergleich der "Leistungsfähigkeit" schneiden die Sockets gar nicht soo schlecht ab, der TClientSocket ist absolut nicht den Indies hinterherstehend, lediglich der TServerSocket ist halt "nur" monolithisch, wenn man die Client-Ereignisse nutzt, anstatt eine eigene Client-Thead-Klasse beim Connect zu übergeben (konkret bedeutet das, das der TServerSocket durchaus multithreaded ist/sein kann, aber eben mit Zusatzaufwand).

Fazit: Wenn du nicht in kommerziellen Dimensionen Last zu bedienen hast (und das dürfte mal eher selten der Fall sein), dann sind die Sockets zwar "alt", aber noch lange nicht "schlecht".

Tristan hat folgendes geschrieben:

Ich habe das Problem... [...] Das Resultat: nicht alle Clients können sich anmelden bzw. es kommt zu irgendwelchen Überläufen.

Wenn ich mir das so ansehe, dann muss ich leider sagen, dass da der "Teufel" wohl eher in deinem Konzept liegt; ich bezweifle, dass dir eine andere Komponente da helfen wird... :? :|

Tristan hat folgendes geschrieben:

Die gesuchte Komponente müsste also mehrere Verbindungen aufnehmen können - möglichst in Echtzeit.

Diese "Funktionalität" wird von der WSA bereitgestellt, egal welchen Wrapper du in Komponentenform einsetzt, wenn´s da hakt, dann liegt das eher selten an dem Wrapper... ;)

Aus meiner eigenen Erfahrung: Ich kann deine beschriebenen Fehlfunktionen nicht bestätigen, das ist nicht ein Problem der Socket-Kompos - auch wenn die API/das Konzept veraltet ist.

cu
Narses