Du beziehst Dich aber auf long polling, bei dem der Client einen extra Thread startet, der bis zur Antwort vom Server blockiert - richtig?
Genau.
Dann muss aber auch der Server eine Connection pro Client offen halten - richtig?
Das würde bedeuten, dass man nicht tausende sondern höchstens hunderte Clients verbinden kann - richtig?
TCP Connections hält man bei solchen Anwendungsfällen eigentlich immer permanent offen. Unter Windows kannst du mit einem
IOCP Server durchaus auch tausende Verbindungen gleichzeitig offen halten. Hierbei wird dann nicht pro eingehender Client Verbindung ein Thread erstellt, sondern ein Thread-Pool genutzt.
Wenn der Client keine Antwort vom Server erhält (was ja der Standardfall sein sollte) und seinerseits jetzt Änderungen veranlassen oder weitere Daten abrufen will, muss er dann eine weitere Verbindung aufbauen oder kann er den wartenden Thread abbrechen, seine Kommunikation abwickeln und wieder in den Wartemodus gehen?
Das sollte gehen. Eventuell solltest du dir aber auch mal UDP (und eventuell das
enet-Protokoll) anschauen. Bei UDP bleiben keine dauerhaften Verbindungen offen und es ist performanter, wenn du viele schnelle Änderungen übertragen willst (besonders, wenn es nicht so wichtig ist, dass wirklich ALLE Pakete ankommen). Würde ich aber nur dann in Betracht ziehen, wenn du immer einen kompletten Kontext übertragst und nicht bei inkrementellen Änderungen (da bei UDP nicht garantiert ist, dass die Pakete überhaupt und in der richtigen Reihenfolge ankommen).
Indys hätten keine Nachteile gegenüber blockierenden Sockets, abgesehen von den erweiterten Möglichkeiten und unterstützen Protokollen?
Also die Kommunikation und der Ablauf an sich wären quasi identisch - richtig?
Das stimmt. Die Indys sind sogar glaube ich standardmäßig auch auf blocking eingestellt.