Nicht blockierender Socket mit Abfrage

Vor ein paar Tagen musste ich ein Problem untersuchen, bei dem meine Anwendung eine ungewöhnlich hohe CPU-Auslastung zeigte, wenn sie sich (anscheinend) im Leerlauf befand. Ich habe das Problem bis zu einer Schleife verfolgt, die auf a blockieren sollte recvfrom anrufen, während die Steckdose auf eingestellt war O_NONBLOCK-ing, was zu einem Spinlock führt. Zur Lösung des Problems gab es zwei Möglichkeiten: Socket auf Blocking setzen oder verfügbare Daten auf dem Socket abfragen mit poll oder select. Ich habe mich für Ersteres entschieden, da es einfacher ist. Aber ich frage mich, warum jemand einen nicht blockierenden Socket erstellen und ihn dann separat abfragen würde. Tut eine blockierende Steckdose nicht dasselbe? In welchen Anwendungsfällen würde man eine Kombination aus nicht blockierendem Socket und Abfrage verwenden? Gibt es Vorteile im Allgemeinen?

Verwenden poll() oder select() mit einem nicht blockierenden Dateideskriptor bietet Ihnen zwei Vorteile:

• Sie können ein Zeitlimit für die Blockierung festlegen;
• Sie können auf eines von a warten einstellen von Dateideskriptoren nutzbar zu machen.

Wenn Sie nur auf einen einzigen Dateideskriptor (Socket) warten müssen und es Ihnen nichts ausmacht, auf unbestimmte Zeit darauf zu warten, dann ja; Sie können einfach einen blockierenden Anruf verwenden.

Der zweite Vorteil ist wirklich der Killer-Use-Case für select() und Freunde. Das bedeutet, dass Sie mehrere Socket-Verbindungen sowie Standardeingabe und Standardausgabe und möglicherweise Datei-I/O mit einem einzigen Steuerungs-Thread handhaben können.

Ich poste hier, weil die Frage zwar alt ist. Es ist irgendwie in meiner Google-Suche aufgetaucht und wurde definitiv nicht richtig beantwortet.

Die akzeptierte Antwort hebt lediglich zwei Vorteile der Verwendung nicht blockierender Sockets hervor, geht jedoch nicht wirklich ins Detail oder beantwortet die eigentliche Frage.

• HINWEIS: Leider enthalten die meisten Online-“Tutorials” oder Code-Snippets nur blockierenden Socket-Code, sodass das Wissen über nicht blockierende Sockets weniger verbreitet ist.

Wann würden Sie das eine im Vergleich zum anderen verwenden … im Allgemeinen werden blockierende Sockets nur in Online-Code-Snippets verwendet. In allen (guten) Produktionsanwendungen werden nicht blockierende Buchsen verwendet. Ich bin nicht unwissend, wenn Sie eine Implementierung kennen, die blockierende Sockets verwendet (und sicher ist, dass dies in Kombination mit Threads sehr gut möglich ist) – oder genauer gesagt, die blockierende Sockets in einem einzelnen Thread verwendet – lassen Sie es bitte ich weiß.

Jetzt kann ich Ihnen ein sehr leicht verständliches Beispiel geben, und es gibt noch viele andere da draußen. Nehmen wir das Beispiel eines Gaming-Servers. Spiele schreiten in Ticks fort, in regelmäßigen Intervallen, in denen der Spielstatus fortschreitet, unabhängig davon, ob der Spieler Eingaben (Maus/Tastatur) vornimmt oder nicht, um den Status des Spiels zu ändern. Wenn jetzt Sockets in Multiplayer-Spielen ins Spiel kommen – wenn Sie blockierende Sockets verwenden würden, würde der Spielstatus nicht fortschreiten, es sei denn, die Spieler senden Updates – wenn sie also Internetprobleme haben, würde der Spielstatus niemals konsistent aktualisiert und Änderungen an alle Spieler weitergegeben . Sie würden eine ziemlich abgehackte Erfahrung haben.

Wenn Sie jetzt nicht blockierende Sockets verwenden, können Sie den Gameserver in einem Single-Thread ausführen und den Spielstatus sowie die Sockets aktualisieren, mit einem … sagen wir 50 ms Timeout-Intervall – und Socket-Daten werden nur dann von verbundenen Benutzern gelesen Sie senden tatsächlich etwas und speisen es dann in die Serversimulation ein, verarbeiten es und speisen es in die Spielzustandsberechnung für den nächsten Tick ein.

was zu einem Spinlock führt.

Dieser Zustand wird normalerweise als a bezeichnet enge Schleife.

Zur Lösung des Problems gab es zwei Möglichkeiten: Den Socket auf Blocking setzen oder mit poll oder select nach verfügbaren Daten auf dem Socket pollen. Ich habe mich für Ersteres entschieden, da es einfacher ist.

Sind Sie sicher, dass andere Codeteile nicht bereits verwendet werden poll() (oder select()) und erwarten, dass sich der Socket im nicht blockierenden Modus befindet?

Ansonsten, dann ja, der Wechsel in den Sperrmodus ist die einfachste Lösung.

Am besten abwärtskompatible Lösung wäre vor dem Aufruf gewesen recvfrom() benutzen poll() warten, bis der Socket lesbar wird. Auf diese Weise wird sichergestellt, dass andere Teile des Codes genauso funktionieren wie zuvor.

Aber ich frage mich, warum jemand einen nicht blockierenden Socket erstellen und ihn dann separat abfragen würde. Tut eine blockierende Steckdose nicht dasselbe?

Für den Fall von recvfrom() mir ist kein großer unterschied bekannt.

In welchen Anwendungsfällen würde man eine Kombination aus nicht blockierendem Socket und Abfrage verwenden? Gibt es Vorteile im Allgemeinen?

Könnte ein einfacher Codierungsfehler sein. Oder jemand hätte gedacht, dass Recv’ing in Tight Loop die Leistung irgendwie steigern würde.

Es ist immer besser, Steckdosen als zu machen nonblocking denn selbst ein blockierender Socket wird manchmal bereit (wenn Daten angekommen sind, aber einen Prüfsummenfehler aufweisen und dieser verworfen wird) – selbst wenn keine Daten zum Lesen vorhanden sind. Also mach es nonblocking, warten Sie auf die Datenverfügbarkeit durch Abfrage und lesen Sie dann. Ich denke, das ist der Hauptvorteil.