gleichzeitiges Lesen und Schreiben auf demselben Socket in C oder C++

Ich implementiere einen einfachen Server, der eine einzelne Verbindung akzeptiert und dann diesen Socket verwendet, um gleichzeitig Nachrichten aus den Lese- und Schreibthreads zu lesen und zu schreiben. Was ist die sichere und einfache Möglichkeit, gleichzeitig von demselben Socket-Deskriptor in c/c++ unter Linux zu lesen und zu schreiben? Ich muss mich nicht um mehrere Threads kümmern, die von demselben Socket lesen und schreiben, da es einen einzigen dedizierten Lese- und einen einzigen dedizierten Schreib-Thread gibt, der in den Socket schreibt.

Ist im obigen Szenario irgendeine Art von Sperrung erforderlich?

Erfordert das obige Szenario einen nicht blockierenden Socket?

Gibt es eine Opensource-Bibliothek, die im obigen Szenario helfen würde?

Ist im obigen Szenario irgendeine Art von Sperrung erforderlich?

Keiner.

Erfordert das obige Szenario einen nicht blockierenden Socket?

Das bisschen, worüber Sie sich wahrscheinlich Sorgen machen – das read/recv und write/send Threads auf eine bestehende Verbindung – zu tun nicht müssen nicht blockierend sein, wenn Sie froh sind, dass diese Threads dort sitzen und darauf warten, abgeschlossen zu werden. Das ist normalerweise einer der Gründe, warum Sie eher Threads verwenden würden select, epoll, asynchrone Operationenoder io_uring – hält den Code auch einfacher.

Wenn der Thread neue Clients akzeptiert, blockiert er gerne den Aufruf an accept()dann bist du auch dort gut aufgehoben.

Dennoch gibt es ein subtiles Problem mit TCP-Servern, das Sie vielleicht im Hinterkopf behalten sollten … wenn Ihr Programm wächst, um mehrere Clients zu verwalten und einige regelmäßige Haushaltsarbeiten zu erledigen hat. Es ist natürlich und verlockend, a zu verwenden select oder epoll Rufen Sie dann mit einem Timeout auf, um die Lesbarkeit auf dem lauschenden Socket zu prüfen – was auf einen Verbindungsversuch des Clients hinweist accept die Verbindung. Es gibt dort eine Race-Bedingung: Der Client-Verbindungsversuch wurde möglicherweise unterbrochen select() und accept()in welchem ​​Fall accept() wird blockieren, wenn die lauschende Steckdose nicht nicht blockierend ist, und das kann eine rechtzeitige Rückkehr zum verhindern select() Schleife und halten Sie die periodische On-Timeout-Verarbeitung an, bis ein anderer Client eine Verbindung herstellt.

Gibt es eine Opensource-Bibliothek, die im obigen Szenario helfen würde?

Es gibt Hunderte von Bibliotheken zum Schreiben von Basisservern (und nach Lib-Empfehlungen von Drittanbietern zu fragen, ist bei SO kein Thema, daher werde ich nicht darauf eingehen), aber letztendlich ist das, wonach Sie gefragt haben, leicht auf einem bereitgestellten Betriebssystem zu erreichen BSD-Sockets-API oder die Windows-Bastardisierung (“winsock”).

Sie müssen sich keine Sorgen machen. Ein Thread-Lesen und ein Thread-Schreiben funktionieren wie erwartet. Sockets sind Vollduplex, sodass Sie lesen können, während Sie schreiben, und umgekehrt. Sie müssten sich Sorgen machen, wenn Sie mehrere Autoren hätten, aber das ist nicht der Fall.

Steckdosen sind BIDIREKTIONAL. Wenn Sie jemals ein Ethernet- oder serielles Kabel seziert oder den Low-Level-Hardware-Verdrahtungsplan dafür gesehen haben, können Sie tatsächlich deutliche Kupferdrähte für die Leitungen „TX“ (Senden) und „RX“ (Empfangen) SEHEN. Die Software zum Senden der Signale, von der Gerätesteuerung bis zu den meisten Betriebssystem-APIs für einen „Socket“, spiegelt dies wider und ist der Hauptunterschied zwischen einem Socket und einer gewöhnlichen Pipe auf den meisten Systemen (z. B. Linux).

Um Steckdosen wirklich optimal nutzen zu können, benötigen Sie:
1) Asynchrone IO-Unterstützung, die IO Completion Ports, epoll() oder ein ähnliches asynchrones Rückruf- oder Ereignissystem verwendet, um „aufzuwachen“, wenn Daten auf dem Socket eingehen. Dies muss dann Ihre ‘ReadData’-API auf der niedrigsten Ebene aufrufen, um die Nachricht von der Socket-Verbindung zu lesen.
2) Eine zweite API, die Low-Level-Schreibvorgänge unterstützt, ein ‘WriteData’ (Senden), das Bytes auf den Socket schiebt und von nichts abhängt, was die ‘ReadData’-Logik benötigt. Denken Sie daran, dass Ihr Senden und Empfangen sogar auf Hardwareebene unabhängig sind, führen Sie also auf dieser Ebene keine Sperrung oder andere Synchronisierung ein.
3) Ein Pool von Socket-IO-Threads, die blind jede Verarbeitung von Daten ausführen, die von einem Socket gelesen oder in einen Socket geschrieben werden.
4) PROTOKOLL-CALLBACK: Ein Callback-Objekt, auf das die Socket-Threads intelligente Zeiger haben. Es behandelt jede PROTOCOL-Schicht – wie das Parsen Ihres Daten-Blobs in eine echte HTTP-Anforderung – die auf der grundlegenden Socket-Verbindung sitzt. Denken Sie daran, dass ein Socket nur eine Datenleitung zwischen Computern ist und die darüber gesendeten Daten oft als eine Reihe von Fragmenten ankommen – die Pakete. Bei Protokollen wie UDP sind die Pakete nicht einmal geordnet. Die ‘ReadData’ und ‘WriteData’ auf niedriger Ebene werden von ihren Threads hierher zurückgerufen, da hier die inhaltsbewusste Datenverarbeitung tatsächlich beginnt.
5) Alle Rückrufe, die der Protokoll-Handler selbst benötigt. Für HTTP packen Sie die rohen Anforderungspuffer in nette Objekte, die Sie an ein echtes Servlet übergeben, das ein nettes Antwortobjekt zurückgeben sollte, das in eine HTTP-Spezifikations-konforme Antwort serialisiert werden kann.

Beachten Sie das grundlegende Muster: Sie müssen das gesamte System grundlegend asynchron machen (eine „Zwiebel von Rückrufen“), wenn Sie die Vorteile der bidirektionalen, asynchronen E/A über Sockets voll ausschöpfen möchten. Die einzige Möglichkeit, gleichzeitig in den Socket zu lesen und zu schreiben, sind Threads, sodass Sie immer noch zwischen einem ‘Writer’- und ‘Reader’-Thread synchronisieren könnten, aber ich würde es nur tun, wenn das Protokoll oder andere Überlegungen mich dazu zwingen würden. Die gute Nachricht ist, dass Sie mit Sockets mit stark asynchroner Verarbeitung eine hervorragende Leistung erzielen können. Die schlechte ist, dass der Aufbau eines solchen Systems auf robuste Weise eine ernsthafte Anstrengung darstellt.