close() est de ne pas fermer correctement le connecteur

Voici un code que j'ai utilisé sur de nombreux systèmes Unix (e.g SunOS 4, SGI IRIX, hp-ux 10.20, CentOS 5, Cygwin) pour fermer un socket:

int getSO_ERROR(int fd) {
   int err = 1;
   socklen_t len = sizeof err;
   if (-1 == getsockopt(fd, SOL_SOCKET, SO_ERROR, (char *)&err, &len))
      FatalError("getSO_ERROR");
   if (err)
      errno = err;              //set errno to the socket SO_ERROR
   return err;
}

void closeSocket(int fd) {      //*not* the Windows closesocket()
   if (fd >= 0) {
      getSO_ERROR(fd); //first clear any errors, which can cause close to fail
      if (shutdown(fd, SHUT_RDWR) < 0) //secondly, terminate the 'reliable' delivery
         if (errno != ENOTCONN && errno != EINVAL) //SGI causes EINVAL
            Perror("shutdown");
      if (close(fd) < 0) //finally call close()
         Perror("close");
   }
}

Mais le ci-dessus ne garantit pas qu'un tampon d'écriture est envoyé.

Gracieux près: Il m'a fallu environ 10 ans pour comprendre comment fermer un socket. Mais pour un autre 10 ans, j'ai paresseusement appelé usleep(20000) pour un léger retard pour "assurer" que la mémoire tampon d'écriture a été rincé avant de le fermer. De toute évidence, cela n'est pas très intelligent, parce que:

• Le délai était trop long la plupart du temps.
• Le délai était trop court de temps en temps, peut-être!
• Un signal de telles SIGCHLD pourrait se produire à la fin de usleep() (mais j'ai l'habitude appelé usleep() deux fois pour gérer ce cas--un hack).
• Il n'y a aucune indication que cela fonctionne. Mais c'est peut-être pas important si l') réinitialise dur sont parfaitement ok, et/ou b) vous avez le contrôle sur les deux côtés de la liaison.

Mais faire une bonne chasse est étonnamment difficile. À l'aide de SO_LINGER est apparemment pas la voie à suivre; voir, par exemple:

• http://msdn.microsoft.com/en-us/library/ms740481%28v=vs.85%29.aspx
• https://www.google.ca/#q=the-ultimate-so_linger-page

Et SIOCOUTQ semble être spécifique à Linux.

Note shutdown(fd, SHUT_WR) n'est pas arrêter d'écrire, contrairement à son nom, et peut-être contrairement à man 2 shutdown.

Ce code flushSocketBeforeClose() attend jusqu'à ce qu'une lecture de zéro octets, ou jusqu'à l'expiration de la minuterie. La fonction haveInput() est un simple wrapper pour sélectionner(2), et est configuré pour bloquer jusqu'à 1/100e de seconde.

bool haveInput(int fd, double timeout) {
   int status;
   fd_set fds;
   struct timeval tv;
   FD_ZERO(&fds);
   FD_SET(fd, &fds);
   tv.tv_sec  = (long)timeout; //cast needed for C++
   tv.tv_usec = (long)((timeout - tv.tv_sec) * 1000000); //'suseconds_t'

   while (1) {
      if (!(status = select(fd + 1, &fds, 0, 0, &tv)))
         return FALSE;
      else if (status > 0 && FD_ISSET(fd, &fds))
         return TRUE;
      else if (status > 0)
         FatalError("I am confused");
      else if (errno != EINTR)
         FatalError("select"); //tbd EBADF: man page "an error has occurred"
   }
}

bool flushSocketBeforeClose(int fd, double timeout) {
   const double start = getWallTimeEpoch();
   char discard[99];
   ASSERT(SHUT_WR == 1);
   if (shutdown(fd, 1) != -1)
      while (getWallTimeEpoch() < start + timeout)
         while (haveInput(fd, 0.01)) //can block for 0.01 secs
            if (!read(fd, discard, sizeof discard))
               return TRUE; //success!
   return FALSE;
}

Exemple d'utilisation:

   if (!flushSocketBeforeClose(fd, 2.0)) //can block for 2s
       printf("Warning: Cannot gracefully close socket\n");
   closeSocket(fd);

Ci-dessus, mon getWallTimeEpoch() est similaire à time(), et Perror() est un wrapper pour perror().

Edit: Quelques commentaires:

• Ma première entrée est un peu gênant. Les OP et Nemo contesté le besoin de nettoyer l'intérieur so_error avant de fermer, mais je ne trouver aucune référence à cela. Le système en question était-UX 10.20. Après l'échec d'une connect(), juste appeler close() n'a pas communiqué le descripteur de fichier, parce que le système a souhaité offrir une remarquable erreur pour moi. Mais j'ai, comme la plupart des gens, jamais pris la peine de vérifier la valeur de retour de close. j'ai Donc finalement manqué de descripteurs de fichiers (ulimit -n), qui a finalement obtenu mon attention.

• (très petite), Un commentateur a objecté à la codées en dur des arguments numériques à shutdown(), plutôt que, par exemple, SHUT_WR pour 1. La réponse la plus simple est que Windows utilise différents #définit la/les énumérations, par exemple SD_SEND. Et de nombreux autres auteurs (par exemple, Beej) utiliser des constantes, comme le font de nombreux systèmes hérités.

• Aussi, j'ai toujours, toujours, ensemble FD_CLOEXEC sur toutes mes prises, puisque dans mes applications, je ne veux plus jamais les transmettre à un enfant et, plus important encore, je ne veux pas d'un enfant accroché à l'impact de moi.

Exemple de code pour définir CLOEXEC:

   static void setFD_CLOEXEC(int fd) {
      int status = fcntl(fd, F_GETFD, 0);
      if (status >= 0)
         status = fcntl(fd, F_SETFD, status | FD_CLOEXEC);
      if (status < 0)
         Perror("Error getting/setting socket FD_CLOEXEC flags");
   }

Cela me semble être un bug dans votre distribution Linux.

La Bibliothèque C de GNU de documentation dit:

Lorsque vous avez fini d'utiliser un support, vous pouvez simplement fermer son fichier
descripteur avec close

Rien de compensation tous les indicateurs d'erreur ou d'attente pour les données seront supprimées ou quelque chose de ce genre.

Votre code est très bien; votre O/S a un bug.