Les descripteurs de fichiers sont en effet «hérités» lors du forking, mais uniquement en fonction du socket auquel ils sont connectés, et la fermeture du descripteur de fichier ne fermera le socket que s'il est le dernier associé à ce socket. si nous traitons de fichiers).
Ce que vous faites habituellement, c'est d'établir le socket, puis vous le faites. Dans le processus parent (celui où fork est retourné non nul), vous pouvez aller de l'avant et fermer le descripteur de fichier en utilisant close(fd), sinon vous finirez par manquer de descripteurs de fichiers dans le processus parent. C'est pour les sockets de flux (par exemple TCP), où vous avez un socket serveur à l'écoute des connexions, et un socket par connexion établie. Cependant, vous utilisez UDP, donc il n'y a en fait qu'une seule socket, et si vous avez l'intention de continuer à l'utiliser dans le processus parent, vous aurez besoin de comprendre comment le partager entre le processus parent et enfant. Les deux peuvent continuer à l'utiliser, mais ce sera presque au hasard qui lira quoi, et dans quel ordre les choses seront envoyées. Dans ce cas, vous avez généralement un processus de multiplexage qui reçoit les paquets et les transmet à l'enfant approprié (par un autre mécanisme, tel que des pipes ou d'autres sockets) en fonction du contenu du message (en TCP, c'est l'ip source/port et destination ip/port tuple). Comme Matt l'a fait remarquer, l'utilisation de shutdown rendra le socket inutilisable (généralement non-éditable, mais vous pouvez le spécifier) pour tous les participants. Dans TCP, cela pourrait déclencher l'envoi d'un paquet FIN, initiant effectivement la suppression de la connexion, mais vous pouvez toujours recevoir des données jusqu'à ce que l'extrémité distante reconnaisse le FIN.