Ich habe eine Frage, ich will ein Netzwerkprogramm schreiben, auf den sich mehrere (theoretisch mehr als 100) Clienten anmelden können. Da es aber immer eine gewisse Zeit braucht bis sich ein Soket angemeldet hat frage ich mich wie man das ganze Optimieren kann.

Ich habe mir auch schon gedanken gemacht:

Das Programm erhält zur Zeit einen Befehl über netzwerk (z.B. berechte das Produkt von 4 und 5) diese Prozedure führt er nun aus, und sendet die Antwort zurück und lässt erst dann die nächste anmeldung zu. Deshalb, wäre es mäglich eine Art Speicher zu schreiben, der etwa zu funktioniert:

Client meldet sich an und sendet Befehl
Server speichert den Befehl und trennt verbindung wieder,
so dass sich ein neuer Client anmelden kann.
Und eine Procedure überwacht und verteilt die Befehle mit den einzelnen Clientadressen(damit das Programm auch weiß, was er an wen schicken soll).

Das ist die Theorie, aber ich weiß nicht wie ich das in die Praxis umsetzen kann!!! Könnte mir dabei wohl jemand helfen?

Die Frage war ursprünglich UDP oder TCP. Bei deinem vorhaben (das im übrigen sich sehr nach distributed computing anhört) würde ich dir UDP empfehlen. Du kannst mittels der Indy Library auch bei UDP eine Empfangsbestätigung erhalten. Somit ist UDP eine sichere Sache und schneller als TCP.

ich würd das Protokoll erstmal ausser acht lassen (man kann ja auch pipes nehmen) sondern erstmal gedanken machen wie sowas umzusetzen sei.
IMHO kommt hier nur infrage, jede Clientanfrage in Threads zu beantworten, alles andere macht keinen Sinn. Sequenzielle Anfragen und Antworten kosten so hohe Laufzeiten und sind auch nicht das gelbe vom Ei sozusagen, gerade weil Netzwerkverbindungen eh asynchron ablaufen.

Leider sind 100 Threads kein Pappenstiel und ein 08/15 System geht da in Knie (win9x geht dann erstmal nach nirwana).

Was sollen denn die Clients und der Server überhaupt machen ?

grez
msch

Du musst ja keinen eigenen Thread pro Client erstellen. Unter Win9X kannst du ohnehin nur 16 Threads pro Prozess laufen lassen.