• [^] # Re: Je comprends pas

    Posté par . En réponse au journal Le TCP keepalive m'a tué. Évalué à -1.

    Tu n'as pas l'air d'arriver à comprendre que la couche transport et la couche application ne sont pas la même chose. Entrée numéro 1 du Fallacies of Distributed Computing: The network is reliable.

    Je suis d'accord qu'il y a un choix à faire sur où tu fais la persistance. Le choix de tcp me conforte dans le fait qu'on veut le faire à ce niveau, même si on abuse beaucoup de ce protocole aujourd'hui.

    Par contre, dire que comme le réseau n'est pas fiable ça va foirer est faux_ : justement, tcp est _fait pour supporter les pertes de paquets, et sans keepalive, on peut très bien s'accommoder de pertes temporaires de réseau. La connexion reprendra bien comme il faut quand le réseau aura été réparé.

    C'est étrange comme vous utilisez le keepalive comme un moyen de se parer des problèmes du réseau alors que justement, tcp est fait pour ça !

    Non:
    - une machine qui crash
    - Un arrêt brutal

    C'est les cas que j'ai cité. J'ose espérer qu'ils sont rares.

    • Un câble réseau débranché

    TCP s'en accommodera très bien.

    • Réinitialisation de la table d'état d'un firewall statefull et va tout dropper
    • Un laptop qui passe en veille et ne reprendra jamais l'IP qu'il avait

    Ça c'est les signes d'un réseau pourri. C'est ici qu'il faudrait agir pour résoudre les problèmes. Alors après, bisounours, toussa, mais ça pourrait améliorer beaucoup de choses de régler ce genre de problème.

    Y'a la théorie et la pratique. C'est pour ca qu'on implémente des système qui au minimum survivent aux erreurs et au mieux supportent les pannes byzantines.

    Mais je suis tout à fait d'accord. Et ssh sans keepalive se démerde très bien comme ça !
    Après, si tu changes de réseau ou si un firewall statefull a merdé au milieu, ta session bloque, tu le remarques, tu coupes. Mais dans le premier cas c'est la faute de l'utilisateur, dans le deuxième c'est le signe d'un réseau pourri.