Pourquoi écrire un socket TCP fermé est-il pire que d'en lire un?

Question

Lorsque vous lisez un socket TCP fermé, vous obtenez une erreur régulière, c'est-à-dire qu'il renvoie 0 indiquant EOF ou -1 et un code d'erreur dans errno qui peut être imprimé avec perror.

Cependant, lorsque vous écrivez un socket TCP fermé, le système d'exploitation envoie SIGPIPE à votre application, ce qui mettra fin à l'application si elle n'est pas interceptée. Pourquoi écrire le socket TCP fermé est-il pire que de le lire?

Answer 1

+1 À Greg Hewgill pour diriger mon processus de pensée dans la bonne direction pour trouver la réponse.

La véritable raison de SIGPIPE dans les sockets et les canalisations est l'idiome/modèle de filtre qui s'applique aux E/S typiques dans les systèmes Unix.

À partir de tubes. Les programmes de filtrage comme grep écrivent généralement à STDOUT et lisent à partir de STDIN, qui peuvent être redirigés par le shell vers un canal. Par exemple:

cat someVeryBigFile | grep foo | doSomeThingErrorProne 

quand le réservoir fourches puis ces programmes de exec utilise probablement l'appel système dup2 à redirigent STDIN, STDOUT et STDERR aux tuyaux appropriés. Puisque le programme de filtrage grep ne sait pas et n'a aucun moyen de savoir que sa sortie a été redirigée alors la seule façon de lui dire d'arrêter d'écrire sur un tube rompu si doSomeThingErrorProne se bloque avec un signal puisque les valeurs de retour de écrit au STDOUT sont rarement vérifiées. L'analogue avec les sockets serait le serveur inetd prenant la place de la coquille.

À titre d'exemple, je suppose que vous pouvez transformer grep en un service réseau qui fonctionne sur TCP sockets. Par exemple avec inetd si vous voulez avoir un serveur grep sur TCP port 8000 puis l'ajouter à /etc/services:

grep  8000/tcp # grep server 

Puis ajoutez ceci /etc/inetd.conf:

grep stream tcp nowait root /usr/bin/grep grep foo 

Envoyer SIGHUP-inetd et se connecter au port 8000 avec telnet. Cela devrait provoquer inetd à fork, dup la douille sur STDIN, STDOUT et STDERR et ensuite exec grep avec foo comme argument. Si vous commencez à taper des lignes dans telnet grep fera écho aux lignes qui contiennent foo.

Remplacez maintenant telnet par un programme nommé ticker qui écrit par exemple un flux de cotations boursières en temps réel à STDOUT et obtient des commandes sur STDIN.Quelqu'un se connecte au port 8000 et tape "start java" pour obtenir des devis pour Sun Microsystems. Puis ils se lèvent et vont déjeuner. telnet se bloque inexplicablement. S'il n'y avait aucun SIGPIPE à envoyer alors ticker continuerait à envoyer des citations pour toujours, ne sachant jamais que le processus à l'autre bout s'était écrasé, et gaspillant inutilement des ressources de système.

Answer 2

Généralement, si vous écrivez sur une socket, vous vous attendez à ce que l'autre extrémité soit à l'écoute. C'est un peu comme un appel téléphonique - si vous parlez, vous ne vous attendez pas à ce que l'autre interlocuteur raccroche.

Si vous lisez depuis un socket, vous attendez que l'autre extrémité vous envoie (a) quelque chose, ou (b) ferme le socket. La situation (b) se produirait si vous venez d'envoyer quelque chose comme une commande QUIT à l'autre extrémité.

Answer 3

Je pense qu'une grande partie de la réponse est 'de sorte qu'un socket se comporte plutôt comme un tuyau Unix (anonyme) classique'. Ceux-ci présentent également le même comportement - témoin le nom du signal. Par conséquent, il est raisonnable de se demander pourquoi les tuyaux se comportent de cette façon. La réponse de Greg Hewgill donne un résumé de la situation.

Une autre façon de le regarder est - quelle est l'alternative? Est-ce qu'un 'read()' sur un tube sans script donne un signal SIGPIPE? La signification de SIGPIPE devrait changer de 'écrire sur un tuyau avec personne pour le lire', bien sûr, mais c'est trivial. Il n'y a pas de raison particulière de penser que ce serait mieux; l'indication EOF (zéro octet à lire, zéro octet lu) est une description parfaite de l'état de la conduite, et donc le comportement de lecture est bon.

Qu'en est-il de 'write()'? Eh bien, une option serait de retourner le nombre d'octets écrits - zéro. Mais ce n'est pas une bonne idée. cela implique que le code devrait réessayer et peut-être que plus d'octets seraient envoyés, ce qui ne sera pas le cas. Une autre option serait une erreur - write() renvoie -1 et définit un errno approprié. Ce n'est pas clair qu'il y en a un. EINVAL ou EBADF sont tous les deux inexacts: le descripteur de fichier est correct et ouvert à cette fin (et devrait être fermé après l'écriture défaillante); il n'y a tout simplement rien pour le lire. EPIPE signifie «PIPE cassé»; donc, avec une mise en garde à propos de "ceci est une douille, pas un tuyau", ce serait l'erreur appropriée. C'est probablement l'errno renvoyé si vous ignorez SIGPIPE. Il serait possible de le faire - il suffit de renvoyer une erreur appropriée lorsque le tuyau est cassé (et ne jamais envoyer le signal). Cependant, c'est un fait empirique que de nombreux programmes ne prêtent pas autant d'attention à la destination de leur sortie et si vous passez une commande qui lira un fichier de plusieurs gigaoctets dans un processus qui se ferme après les 20 premiers Ko, mais ne fait pas attention à l'état de ses écritures, alors il faudra beaucoup de temps pour finir, et va gaspiller l'effort de la machine en faisant cela, alors qu'en lui envoyant un signal qu'il n'ignore pas, il s'arrêtera rapidement - ceci est certainement avantageux. Et vous pouvez obtenir l'erreur si vous le souhaitez. Ainsi, l'envoi de signaux a des avantages pour les o/s dans le contexte des tuyaux; et les douilles imitent les tuyaux plutôt étroitement.

Intéressant côté: tout en vérifiant le message pour SIGPIPE, j'ai trouvé l'option de socket:

#define SO_NOSIGPIPE 0x1022 /* APPLE: No SIGPIPE on EPIPE */ 

Answer 4

Pensez à la prise comme un grand pipeline de données entre l'envoi et le processus de réception. Maintenant, imaginez que le pipeline a une vanne qui est fermée (la connexion de la prise est fermée).

Si vous lisez depuis le socket (en essayant de sortir quelque chose du tuyau), il n'y a aucun mal à essayer de lire quelque chose qui n'est pas là; vous n'obtiendrez pas de données. En fait, vous pouvez, comme vous l'avez dit, obtenir un EOF, ce qui est correct, car il n'y a plus de données à lire.

Cependant, écrire à cette connexion fermée est une autre question. Les données ne passeront pas, et vous pourriez finir par laisser tomber une communication importante sur le sol. (Vous ne pouvez pas envoyer d'eau dans un tuyau avec une valve fermée, si vous essayez, quelque chose va probablement éclater quelque part, ou, à tout le moins, la contre-pression va pulvériser de l'eau partout.) Voilà pourquoi il y a un outil pour vous alerter de cette condition, à savoir, le signal SIGPIPE.

Vous pouvez toujours ignorer ou bloquer le signal, mais vous le faites à vos risques et périls.