Gibt es im Allgemeinen eine Geschwindigkeits- oder Leistungsdifferenz bei blockierenden und nicht blockierenden Winsock TCP Sockets? Ich könnte die Unterschiede beider Sockets bekommen, aber es gibt keinen detaillierten Leistungsvergleich zwischen den beiden Typen.Geschwindigkeits-/Leistungsmerkmale von blockierendem gegen nicht blockierendem Winsock
Antwort
Weil es nicht um Geschwindigkeit geht. Die Operationen write
und read
sind nur Speicher kopieren in Verkleidung. Alles, was sie tun, ist das Kopieren von Daten zum bzw. vom Kernel. I.e. sie tatsächlich nichts senden oder empfangen.
Die blockierende vs nonblocking Funktion fragt: Bevorzugen Sie diese Operationen zu blockieren, bis abgeschlossen oder -1 und EAGAIN
zurückzugeben, wenn sie nicht sofort ausgeführt werden können? Zum Beispiel, Sie lesen von einem Socket, aber es gibt nichts im Empfangspuffer. Haben Sie lieber recv
hängen, bis etwas kommt oder -1 EAGAIN
zurückgeben?
Danke für die Aufklärung. –
Es ist eine Tarnung mit IOCP, bei der Benutzer-Pufferzeigerarrays mit den WSASend/WSARecv-Aufrufen in den Kernel kommuniziert werden. Es gibt noch einige Datenbewegungen, aber ich nehme an, dass die NIC-Hardware-Puffer direkt in die Benutzerraum-Puffer DMA'd werden können - schneidet eine Stufe des miserablen Kopierens aus. –
Meiner Erfahrung nach sind nicht blockierende Winsock-Vorgänge etwas langsamer, aber viel besser skalierbar. Tatsache ist, dass Sie zwei Systemaufrufe und ein gewisses Dispatching auf Anwendungsebene ausführen müssen, wenn Sie nicht blockierende E/A (mit IOCP) und einen Systemaufruf ausführen, wenn Sie blockierende E/A verwenden. Wenn Sie viele gleichzeitige Verbindungen haben, ist blockierungsfreie E/A viel schneller, da die Architektur besser skalierbar ist.
Wenn Sie Daten von Punkt zu Punkt mit maximaler Bandbreite übertragen müssen, verwenden Sie blockierende E/A. Wenn Sie viele gleichzeitige Clientverbindungen verarbeiten müssen, verwenden Sie nicht blockierende E/A. Erwarte nicht zu viel von ihnen.
Im Allgemeinen ist dies mehr über "Event-Driven vs Threaded" Server-Architektur dann "Blocking vs Nonblocking". Es gibt keine universelle Serverarchitektur, die in jeder Situation verwendet werden kann. Es hängt von der Anwendung ab.
- 1. YouTube UITableView-Zellen mit UIWebView blockierendem Thread?
- 2. SSL_accept mit flankengetriggertem, nicht blockierendem epoll gibt immer SSL_ERROR_WANT_READ zurück
- 3. Winsock-Programm
- 4. Winsock-Verbindungstest
- 5. Kann einen Winsock-Server nicht hosten
- 6. Timeouts in Winsock-Programmierung
- 7. Winsock 2 Portabilität
- 8. Beispiele für Winsock?
- 9. Portierung von Winsock auf Linux Sockets
- 10. winsock Socket-Fehler
- 11. Mischen von Dateigriffen und Sockets in Winsock
- 12. C++ WinSock Daten von PHP Seite erhalten?
- 13. Dateiübertragung mit Winsock
- 14. C++ Winsock wird Freeze Empfangen von Daten
- 15. Winsock verwarf keine Warnungen
- 16. Winsock sendet leere Daten
- 17. C++ - Umwege WinSock Hooking
- 18. Inhalt von localhost mit winsock holen
- 19. C++ Winsock - accept()
- 20. Winsock Client- und Serverkommunikation
- 21. Winsock Port Listener
- 22. Winsock-Server-Problembehandlung
- 23. Winsock-Fehlercode 10014
- 24. Sichern von SSJS gegen nicht verifizierten Code
- 25. Raw Ethernet Frames mit Winsock
- 26. Können Winsock-Verbindungen zufällig fehlschlagen?
- 27. Kristallraum gegen Irrlicht gegen .....?
- 28. Winsock - Problem mit dem Verbinden
- 29. Check ist Buchse (Winsock spezifisch)
- 30. Winsock recv hooking mit Detours
Wenn überhaupt, würde ich diese Frage als C nicht C++ markieren. –