Et comment il sait que tu es toujours vivant et reviendra?
Il ne peut pas le savoir.
Je comprend rien : le serveur doit bien un jour purger ses connexions fantômes sous peine de crouler sous le nombre de connexion fantômes, et je ne vois pas ta proposition pour gérer le bordel?
Non, en disant ça tu assumes un certain nombre d'idées préconçues fausses.
Déjà, comment définir une connexion « fantôme » ? Certains disent que c'est une connexion qui n'a pas eu d'activité depuis 5 minutes. Moi je trouve ça naze. La RFC définissant TCP ne défini explicitement pas de telle chose.
Notons, au passage, qu'une connexion qui ne répond plus d'un côté ou d'un autre sera considérée morte après le timeout classique (30s je crois avant première retransmission, puis vraiment morte peu après, avec éventuellement d'autres retransmissions). Mais une connexion qui n'a pas de donnée à transférer n'a pas à mourir. Ces cas sont détaillés dans le paragraphe 4.3.3 de la RFC 675, définissant TCP [http://tools.ietf.org/html/rfc675#section-4.3.3].
Ensuite, il existerait un danger de ces connexions « fantômes » (en plus, c'est un mot qui fait peur). Oui, ton serveur va garder le contexte de ces sessions un certain temps ; et alors ? Si tu as perdu des connexions, c'est à dire si tu as eu un plantage, ou que tu n'as pas pu fermer ces connexions quand tu étais sur le réseau duquel elle venait, c'est à toi de les tuer à la prochaine connexion.
Si tu veux vraiment « gérer » le bordel, purges régulièrement les connexions TCP qui ont plus de X jours, par exemple. Ça correspond à mettre un keepalive de X jours, mais ça n'est pas de cette manière dont il est utilisé aujourd'hui.
En fait, j'ai l'impression que tout le monde imagine que c'est un « problème ». Avoir des sessions ssh qui tombent toutes seules toutes les 5 minutes est pour moi un problème plus grand.
Comment savoir que tu vas revenir (dans plusieurs jours) ou pas (tu meurs violement dans un accident avec ton PC alors que tu as dit que tu revenais)?
Il ne se saura pas. Mais s'il purge ma connexion 30 jours après ma mort par exemple, je ne lui en voudrais pas trop.
Tout le problème est là : vous voulez absolument contrôler quelque chose sur lequel vous ne devriez pas avoir le contrôle.
[^] # Re: man ssh
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 0.
Il ne peut pas le savoir.
Non, en disant ça tu assumes un certain nombre d'idées préconçues fausses.
Déjà, comment définir une connexion « fantôme » ? Certains disent que c'est une connexion qui n'a pas eu d'activité depuis 5 minutes. Moi je trouve ça naze. La RFC définissant TCP ne défini explicitement pas de telle chose.
Notons, au passage, qu'une connexion qui ne répond plus d'un côté ou d'un autre sera considérée morte après le timeout classique (30s je crois avant première retransmission, puis vraiment morte peu après, avec éventuellement d'autres retransmissions). Mais une connexion qui n'a pas de donnée à transférer n'a pas à mourir. Ces cas sont détaillés dans le paragraphe 4.3.3 de la RFC 675, définissant TCP [http://tools.ietf.org/html/rfc675#section-4.3.3].
Ensuite, il existerait un danger de ces connexions « fantômes » (en plus, c'est un mot qui fait peur). Oui, ton serveur va garder le contexte de ces sessions un certain temps ; et alors ? Si tu as perdu des connexions, c'est à dire si tu as eu un plantage, ou que tu n'as pas pu fermer ces connexions quand tu étais sur le réseau duquel elle venait, c'est à toi de les tuer à la prochaine connexion.
Si tu veux vraiment « gérer » le bordel, purges régulièrement les connexions TCP qui ont plus de X jours, par exemple. Ça correspond à mettre un keepalive de X jours, mais ça n'est pas de cette manière dont il est utilisé aujourd'hui.
En fait, j'ai l'impression que tout le monde imagine que c'est un « problème ». Avoir des sessions ssh qui tombent toutes seules toutes les 5 minutes est pour moi un problème plus grand.
Il ne se saura pas. Mais s'il purge ma connexion 30 jours après ma mort par exemple, je ne lui en voudrais pas trop.
Tout le problème est là : vous voulez absolument contrôler quelque chose sur lequel vous ne devriez pas avoir le contrôle.