Warum wird angenommen, dass send möglicherweise mit weniger als den angeforderten Daten zurückkehrt, die auf einem blockierenden Socket übertragen werden?

Die Standardmethode zum Senden von Daten über einen Stream-Socket bestand schon immer darin, send mit einem zu schreibenden Datenblock aufzurufen, den Rückgabewert zu überprüfen, um festzustellen, ob alle Daten gesendet wurden, und dann erneut send aufzurufen, bis die gesamte Nachricht akzeptiert wurde.

Dies ist beispielsweise ein einfaches Beispiel für ein allgemeines Schema:

int send_all(int sock, unsigned char *buffer, int len) {
  int nsent;

  while(len > 0) {
    nsent = send(sock, buffer, len, 0);
    if(nsent == -1) // error
      return -1;

    buffer += nsent;
    len -= nsent;
  }
  return 0; // ok, all data sent
}

Sogar die BSD-Manpage erwähnt das

…Wenn am Socket kein Platz für Nachrichten verfügbar ist, um die zu übertragende Nachricht aufzunehmen, dann send() normalerweise blockiert…

Was darauf hinweist, dass wir davon ausgehen sollten, dass send möglicherweise zurückkehrt, ohne alle Daten zu senden. Nun finde ich das ziemlich kaputt, aber selbst W. Richard Stevens geht davon in seinem Standard-Nachschlagewerk etwa aus Netzwerkprogrammierungnicht in den Anfangskapiteln, aber die fortgeschritteneren Beispiele verwenden seine eigene Funktion writen (alle Daten schreiben), anstatt write aufzurufen.

Jetzt halte ich dies immer noch für mehr oder weniger kaputt, denn wenn send nicht in der Lage ist, alle Daten zu übertragen oder die Daten im zugrunde liegenden Puffer zu akzeptieren und der Socket blockiert, dann sollte send blockieren und zurückkehren, wenn die gesamte Sendeanforderung akzeptiert wurde .

Ich meine, im obigen Codebeispiel passiert, wenn send mit weniger gesendeten Daten zurückkehrt, dass es direkt mit einer neuen Anfrage erneut aufgerufen wird. Was hat sich seit dem letzten Aufruf geändert? Beim Maximum sind einige hundert CPU-Zyklen vergangen, sodass der Puffer noch voll ist. Wenn send jetzt die Daten akzeptiert, warum konnte es sie vorher nicht akzeptieren?

Andernfalls werden wir mit einer ineffizienten Schleife enden, in der wir versuchen, Daten an einen Socket zu senden, der keine Daten akzeptieren kann, und es weiter versuchen, oder?

Es scheint also, als ob die Problemumgehung, falls erforderlich, zu stark ineffizientem Code führt, und unter diesen Umständen sollten blockierende Sockets überhaupt vermieden werden und stattdessen nicht blockierende Sockets zusammen mit select verwendet werden.

Was in der obigen Beschreibung fehlt, ist, dass Systemaufrufe unter Unix möglicherweise durch Signale unterbrochen werden. Das ist genau der Grund für die Sperrung send(2) könnte eine kurze Zählung zurückgeben.