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
There are 10 types of people - those who understand binary and those who don´t.