Ah, pardon, merci de l'info. J'avais l'impression que c'était plus court, et j'avais 300s dans la tête pour je ne sais quelle raison. Mais ça le fait effectivement en général pour des temps d'absence assez longs.
Oui. Des laptops qui freezent, j'en vois 4x par jour. Sans compter les autres problèmes.
Et qui freezent avec des connexions ssh ouvertes ? C'est du windows, ou pas ? Ça mettrait tant de sessions fantômes que ça qu'un keepalive à une semaine ne serait pas assez ?
Fréquence aléatoire. Ca peut arriver très fréquemment quand tu as un switch qui déconne, une carte réseau defectueuse etc.
Et ça te coupe des sessions tcp si souvent que ça ? C'est des switchs qui font firewall statefull ? La carte réseau défectueuse ça arrive vraiment très fréquemment ? Comme j'ai déjà dit, je n'ai pas travaillé dans de très gros environnements, mais que ce problème ce conjugue avec des sessions ssh qui passaient par là à ce moment, de manière assez récurrente, ça me paraît tellement pas assez probable pour que ça soit un problème d'envergure. Mais je dois peut-être me tromper.
Quand ca arrive ca peut donner 12 heures de coupure sur Amazon S3 à cause d'un bit flip dans un gossip protocol…
C'est quoi cette histoire ?
Je pense que tu as deux problèmes. Tu considères que les cas d'erreurs sont suffisamment rare pour être ignorés, ne sont pas graves et que les utilisateurs préfèrent réparer les erreurs.
Effectivement, je considère, peut-être à tort, qu'ils sont assez rares pour être ignorés. Que ça soit aux utilisateurs de le réparer, on peut envisager de mettre une sort de keepalive à une semaine (je ne sais pas si c'est réaliste avec un mécanisme de keepalive ; peut-être envisager un système de nettoyage de socket inactives pendant une semaine) afin d'automatiser ça. Mais responsabiliser les utilisateurs, c'est déjà pas mal : tu leurs dis déjà de fermer leur session web correctement, pourquoi pas la même chose avec ssh ? (remarquons au passage que c'est le même problème : ça fait chier les utilisateurs qui ont des sessions http qu'ils veulent faire durer longtemps, quand un site te déco après X minutes d'inactivité)
Et d'autre part tu sembles supposer que les choix fait par TCP sont applicables aux couches du dessus.
Bah, ssh est quand même pour moi vachement lié à tcp, je pense que c'est normal qu'il « subisse » ses choix.
TCP n'offre que le sous ensemble commun nécéssaire à tout les protocoles de couche supérieur. Le keep-alive est vraiment un truc litigieux, qui est d'ailleurs dans une RFC annexe. Ca a été inclus car détecter les pannes est un besoin très courant mais le faire au niveau TCP est assez moisi.
Effectivement. Mais même niveau au-dessus, je ne suis pas fan.
Merci pour ce commentaire constructif en tous cas.
[^] # Re: Je comprends pas
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 2.
Ah, pardon, merci de l'info. J'avais l'impression que c'était plus court, et j'avais 300s dans la tête pour je ne sais quelle raison. Mais ça le fait effectivement en général pour des temps d'absence assez longs.
Et qui freezent avec des connexions ssh ouvertes ? C'est du windows, ou pas ? Ça mettrait tant de sessions fantômes que ça qu'un keepalive à une semaine ne serait pas assez ?
Et ça te coupe des sessions tcp si souvent que ça ? C'est des switchs qui font firewall statefull ? La carte réseau défectueuse ça arrive vraiment très fréquemment ? Comme j'ai déjà dit, je n'ai pas travaillé dans de très gros environnements, mais que ce problème ce conjugue avec des sessions ssh qui passaient par là à ce moment, de manière assez récurrente, ça me paraît tellement pas assez probable pour que ça soit un problème d'envergure. Mais je dois peut-être me tromper.
C'est quoi cette histoire ?
Effectivement, je considère, peut-être à tort, qu'ils sont assez rares pour être ignorés. Que ça soit aux utilisateurs de le réparer, on peut envisager de mettre une sort de keepalive à une semaine (je ne sais pas si c'est réaliste avec un mécanisme de keepalive ; peut-être envisager un système de nettoyage de socket inactives pendant une semaine) afin d'automatiser ça. Mais responsabiliser les utilisateurs, c'est déjà pas mal : tu leurs dis déjà de fermer leur session web correctement, pourquoi pas la même chose avec ssh ? (remarquons au passage que c'est le même problème : ça fait chier les utilisateurs qui ont des sessions http qu'ils veulent faire durer longtemps, quand un site te déco après X minutes d'inactivité)
Bah, ssh est quand même pour moi vachement lié à tcp, je pense que c'est normal qu'il « subisse » ses choix.
Effectivement. Mais même niveau au-dessus, je ne suis pas fan.
Merci pour ce commentaire constructif en tous cas.