Was ist der Unterschied zwischen read() und recv() und zwischen send() und write()?

Was ist der Unterschied zwischen read() und recv()und dazwischen send() und write() in der Socket-Programmierung in Bezug auf Leistung, Geschwindigkeit und andere Verhaltensweisen?

Der Unterschied ist das recv()/send() arbeiten nur mit Socket-Deskriptoren und lassen Sie bestimmte Optionen für die eigentliche Operation angeben. Diese Funktionen sind etwas spezialisierter (z. B. können Sie ein Flag auf Ignorieren setzen SIGPIPEoder um Out-of-Band-Nachrichten zu senden…).

Funktionen read()/write() sind die Universal- Dateideskriptorfunktionen, die auf alle Deskriptoren wirken.

Pro der erste Treffer bei Google

read() entspricht recv() mit einem flags-Parameter von 0. Andere Werte für den flags-Parameter ändern das Verhalten von recv(). In ähnlicher Weise entspricht write() send() mit Flags == 0.

read() und write() sind allgemeiner, sie funktionieren mit jedem Dateideskriptor. Sie funktionieren jedoch nicht unter Windows.

Sie können zusätzliche Optionen an übergeben send() und recv()daher müssen Sie sie möglicherweise in einigen Fällen verwenden.

Das ist mir erst kürzlich aufgefallen, als ich es benutzt habe write() an einem Socket in Windows funktioniert es fast (die FD übergeben an write() ist nicht dasselbe wie das, an das weitergegeben wurde send(); ich benutzte _open_osfhandle() um die FD zu übergeben write()). Es funktionierte jedoch nicht, als ich versuchte, Binärdaten zu senden, die das Zeichen 10 enthielten. write() irgendwo eingefügtes Zeichen 13 davor. Ändern Sie es zu send() mit einem flags-Parameter von 0 wurde dieses Problem behoben. read() könnte das umgekehrte Problem haben, wenn 13-10 in den Binärdaten aufeinanderfolgend sind, aber ich habe es nicht getestet. Aber das scheint ein weiterer möglicher Unterschied zwischen zu sein send() und write().

Eine andere Sache unter Linux ist:

send erlaubt keinen Betrieb auf Nicht-Socket-fd. So zum Beispiel auf USB-Port schreiben, write ist notwendig.

Unter Linux fällt mir auch auf, dass:

Unterbrechung von Systemaufrufen und Bibliotheksfunktionen durch Signalhandler

Wenn ein Signalhandler aufgerufen wird, während ein Systemaufruf oder ein Bibliotheksfunktionsaufruf blockiert ist, dann entweder:

• der Anruf wird automatisch neu gestartet, nachdem der Signalhandler zurückkehrt; oder

• der Aufruf schlägt mit dem Fehler EINTR fehl.

… Die Details variieren je nach UNIX-System; unten die Details für Linux.

Wenn ein blockierter Aufruf an eine der folgenden Schnittstellen von einem Signalhandler unterbrochen wird, wird der Aufruf automatisch neu gestartet, nachdem der Signalhandler zurückkehrt, wenn das Flag SA_RESTART verwendet wurde; ansonsten schlägt der Aufruf mit dem Fehler EINTR fehl:

• lesen(2), readv(2), write(2), writev(2) und ioctl(2) rufen “langsame” Geräte auf.

…..

Die folgenden Schnittstellen werden niemals neu gestartet, nachdem sie von einem Signalhandler unterbrochen wurden, unabhängig von der Verwendung von SA_RESTART; Sie schlagen immer mit dem Fehler EINTR fehl, wenn sie von einem Signalhandler unterbrochen werden:

• “Eingabe”-Socket-Schnittstellen, wenn ein Timeout (SO_RCVTIMEO) auf dem Socket mit setsockopt(2) gesetzt wurde: accept(2), Empf(2),
  recvfrom(2), recvmmsg(2) (ebenfalls mit einem Timeout-Argument ungleich NULL) und recvmsg(2).

• “Output”-Socket-Schnittstellen, wenn ein Timeout (SO_RCVTIMEO) auf dem Socket mit setsockopt(2) gesetzt wurde: connect(2), send(2), sendto(2) und sendmsg(2).

Prüfen man 7 signal für mehr Details.

Eine einfache Verwendung wäre, Signal zu verwenden, um es zu vermeiden recvfrom unbefristet sperren.

Ein Beispiel aus APUE:

#include "apue.h"
#include <netdb.h>
#include <errno.h>
#include <sys/socket.h>

#define BUFLEN      128
#define TIMEOUT     20

void
sigalrm(int signo)
{
}

void
print_uptime(int sockfd, struct addrinfo *aip)
{
    int     n;
    char    buf[BUFLEN];

    buf[0] = 0;
    if (sendto(sockfd, buf, 1, 0, aip->ai_addr, aip->ai_addrlen) < 0)
        err_sys("sendto error");
    alarm(TIMEOUT);
    //here
    if ((n = recvfrom(sockfd, buf, BUFLEN, 0, NULL, NULL)) < 0) {
        if (errno != EINTR)
            alarm(0);
        err_sys("recv error");
    }
    alarm(0);
    write(STDOUT_FILENO, buf, n);
}

int
main(int argc, char *argv[])
{
    struct addrinfo     *ailist, *aip;
    struct addrinfo     hint;
    int                 sockfd, err;
    struct sigaction    sa;

    if (argc != 2)
        err_quit("usage: ruptime hostname");
    sa.sa_handler = sigalrm;
    sa.sa_flags = 0;
    sigemptyset(&sa.sa_mask);
    if (sigaction(SIGALRM, &sa, NULL) < 0)
        err_sys("sigaction error");
    memset(&hint, 0, sizeof(hint));
    hint.ai_socktype = SOCK_DGRAM;
    hint.ai_canonname = NULL;
    hint.ai_addr = NULL;
    hint.ai_next = NULL;
    if ((err = getaddrinfo(argv[1], "ruptime", &hint, &ailist)) != 0)
        err_quit("getaddrinfo error: %s", gai_strerror(err));

    for (aip = ailist; aip != NULL; aip = aip->ai_next) {
        if ((sockfd = socket(aip->ai_family, SOCK_DGRAM, 0)) < 0) {
            err = errno;
        } else {
            print_uptime(sockfd, aip);
            exit(0);
        }
    }

    fprintf(stderr, "can't contact %s: %s\n", argv[1], strerror(err));
    exit(1);
}

“Leistung und Geschwindigkeit”? Sind das nicht so … Synonyme hier?

Jedenfalls die recv() call nimmt das flaggen read() nicht, was es leistungsfähiger oder zumindest bequemer macht. Das ist ein Unterschied. Ich glaube nicht, dass es einen signifikanten Leistungsunterschied gibt, habe es aber nicht getestet.