Was passiert, wenn es mir nicht gelingt, `recv` schnell genug anzurufen?

Ich möchte ein mögliches Szenario berücksichtigen, wo Clients meines TCP/IP-Stream-Socket-Service Daten schneller an meinen Dienst senden, als es verwaltet, um die Daten in seine Puffer zu verschieben (ich spreche natürlich über Anwendungspuffer) mit recv und arbeiten damit. Was passiert also in solchen Szenarien? Offensichtlich muss irgendeine Art von Dienst unter meinem Dienst, der eine Benutzeranwendung ist, einen eingehenden Datenstrom empfangen und irgendwo speichern, bis ich 'Recv' ausstelle, oder? Am sichersten das Betriebssystem. Ich möchte alte Fragen nicht wieder aufmachen, aber ich kann scheinbar keine Antwort auf diese scheinbar offensichtliche finden.Was passiert, wenn es mir nicht gelingt, `recv` schnell genug anzurufen?

Quelle

2011-01-15 amn

TCP bietet flow control. Der TCP-Stack (sowohl auf der Sender- als auch auf der Empfängerseite) wird in der Lage sein, einige Daten für Sie zu puffern, und dies geschieht normalerweise im Betriebssystemkernel.

Wenn die Empfängerpuffer voll sind, weiß der Absender davon und sendet keine weiteren Daten mehr, was dazu führt, dass die sendende Anwendung blockiert (oder anderweitig nicht mehr Daten senden kann), bis wieder Speicherplatz verfügbar ist.

Kurz beschrieben, jedes TCP-Paket (Segment) enthält die Größe der Daten, die gepuffert werden können - die Fenstergröße. Dies bedeutet, dass das andere Ende jederzeit weiß, wie viele Daten es senden kann, ohne dass der Empfänger es wegwirft, weil die Puffer voll sind. Wenn die Fenstergröße 0 wird, sind die Puffer voll und es werden keine Daten mehr gesendet (und wenn der Sender blockiert, wird ein send()-Aufruf blockiert). Theres-Prozeduren zur Überprüfung, ob das TCP-Fenster immer noch 0 ist, kann also fortgesetzt werden erneut, wenn die Daten verbraucht wurden.

Es gibt einige weitere Details here

Quelle

2011-01-15 17:53:09 nos

Nicht ganz. Jede TCP * -Bestätigung * enthält die aktuelle Fenstergröße. Wikipedia ist in diesem Punkt falsch. Die richtige Referenz ist nicht Wikipedia, sondern RFC 793. – EJP

Der Netzwerktreiberstapel verwaltet Datenpuffer (einschließlich der Daten für eingehende Daten). Wenn der Puffer voll ist, werden Folge-TCP-Pakete gelöscht, und der Client versucht, die Daten zu senden. Es gibt ein bisschen mehr auf diesem here und here.

Quelle

2011-01-15 17:47:48

No. A Null Fenster an den Absender geworben wird und der Sender sendet nicht mehr. Letztendlich füllt sich der Sende-Puffer des Senders des Senders und die Anwendung blockiert, es sei denn, sie befindet sich im nicht-blockierenden Modus, in diesem Fall erhält sie EAGAIN oder EWOULDBLOCK. TCP-Pakete würden nur dann gelöscht, wenn der Absender TCP nicht korrekt implementiert und in ein Fenster mit einer Größe von null gesendet hat. – EJP

@EJP Ihr Kommentar ist nur teilweise korrekt. Auf IP-Ebene werden die Pakete * verworfen. Meine Antwort ist falsch in Bezug auf TCP-Pakete (was ich glaube, war ein Tippfehler), aber der Client ist immer noch blockiert (sogar mit Ihrem Kommentar). –

Die Frage ist über TCP. TCP-Segmente bestehen aus IP-Paketen. Auf der IP-Ebene werden die Pakete nur verworfen, wenn die umschließenden Segmente gesendet werden, und sie werden nur gesendet, wenn das Fenster es zulässt, und das Fenster lässt dies nicht zu, so dass sie nicht gesendet werden sollten. – EJP

Was passiert, wenn es mir nicht gelingt, `recv` schnell genug anzurufen?

Antwort

Verwandte Themen