64 Sockets Limit - gültig, falls ja: wie umgehen?
-
Hallo,
früher konnte man mit WSAAsyncSelect()/WSAEventSelect() auf max 64 Sockets gleichzeitig "hören". Mit select() verhielt es sich ähnlich, man musste das FD_SETSIZE Makro umdefinieren (wobei nicht garantiert war, dass de zugrunde liegende Service-Provider tatsächlich auch 64 Sockets unterstützte).Gleiches gilt analog für WaitForMultipleObjects().
Hintergrund der Frage: ich werde wohl einen (einfachen) Server erstellen müssen, der 200-300 Clients parallel bedienen muss. An die IO-Completion-Ports hab ich mich bisher nicht rangetraut. Die scheinen aber wohl die einzige IO-Methode zu sein, die dieses 64-er Limit nicht haben, oder hab ich was falsch verstanden?
-
Nein! Hast Du nicht...
Ansonsten Google:
http://www.winsocketdotnetworkprogramming.com/winsock2programming/winsock2advancediomethod5c.html
https://stackoverflow.com/questions/28625348/what-is-the-maximum-number-of-sockets-that-select-can-handle-in-windows
-
dadiduck schrieb:
... An die IO-Completion-Ports hab ich mich bisher nicht rangetraut. Die scheinen aber wohl die einzige IO-Methode zu sein, die dieses 64-er Limit nicht haben, oder hab ich was falsch verstanden?
Ich hab vor Jahren mal nen IOCP "Netzwerkkern" geschrieben. Es war die Hölle. Ich brauchte Wochen (wenn nicht Monate), um alles zu verstehen und fehlerfrei zu bekommen. Dafür läuft das jetzt richtig super.
Dennoch kann ich dir mittlerweile die ASIO lib empfehlen: https://think-async.com/
Da hab ich mich kürzlich eingearbeitet und es ist eigentlich super einfach, modern, elegant, performant (nutzt auch IOCP). Mehr geht fast nicht
-
dadiduck schrieb:
Hallo,
früher konnte man mit WSAAsyncSelect()/WSAEventSelect() auf max 64 Sockets gleichzeitig "hören". Mit select() verhielt es sich ähnlich, man musste das FD_SETSIZE Makro umdefinieren (wobei nicht garantiert war, dass de zugrunde liegende Service-Provider tatsächlich auch 64 Sockets unterstützte).Wenn du dir die Implementierung der FD_* Makros ansiehst, siehst du wie die "fd sets" aufgebaut sind. Die selbe Struktur kannst du auch direkt in den Speicher schreiben. Damit ist dann egal wie FD_SETSIZE definiert ist.
Das theoretische Problem mit den Service-Providern bleibt dabei natürlich trotzdem. So lange du Windows-eigene verwendest kannst du aber davon ausgehen dass das Limit in neueren Windows Versionen nicht kleiner wird. Ich kann nicht garantieren dass das stimmt (habs nicht ausprobiert), aber ich würde mit wenigstens zigtausenden rechnen.dadiduck schrieb:
Gleiches gilt analog für WaitForMultipleObjects().
Der Unterschied bei WaitForMultipleObjects ist dass das Limit dort "hart" ist, und nicht durch umdefinieren von MAXIMUM_WAIT_OBJECTS umgangen werden kann.
dadiduck schrieb:
Hintergrund der Frage: ich werde wohl einen (einfachen) Server erstellen müssen, der 200-300 Clients parallel bedienen muss. An die IO-Completion-Ports hab ich mich bisher nicht rangetraut. Die scheinen aber wohl die einzige IO-Methode zu sein, die dieses 64-er Limit nicht haben, oder hab ich was falsch verstanden?
Bei 200-300 kannst du auch ohne Probleme einen Thread pro Connection machen. Die Entscheidung ob du einen Thread pro Connection machst oder lieber single threaded bzw. mit einem Worker-Pool arbeitest, solltest du aber vermutlich nicht davon abhängig machen dass select u.U. zu wenig Sockets "kann".
-
So, ich hab mir mal ein Beispiel-Programm mit CompletionPorts angesehen (Echo-Server) und -uff, uff, uff- nach einiger Zeit des Lesens und Probierens tendiere ich in Richtung IOCP. Ich denke, ich habe den Kern der IOCPs verstanden (hoffentlich) und mache mich mal dran.
Den Echo-Server kann ich so weit ausbauen, dass er für meine Zwecke reichen wird.Insgesamt sind die IOCPs also sehr elegant, wenngleich nicht ganz einfach zu begreifen....
Grüße!!1
