ckyl a écrit 3877 commentaires

Mais killer une session qui ne répond pas après 5 minutes (timeout par défaut, il me semble), c'est vraiment court.

sysctl -a 2> /dev/null | grep keep
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

2H comme spécifié par la RFC.

Mais est-ce assez courant pour que ça mérite d'avoir un paramètre par défaut dans un soft comme ssh ?

Oui. Des laptops qui freezent, j'en vois 4x par jour. Sans compter les autres problèmes.

Et ça arrive avec quelle occurrence ? Est-ce que tous les protocoles réimplémentent des checksums au-dessus ?

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. Quand ca arrive ca peut donner 12 heures de coupure sur Amazon S3 à cause d'un bit flip dans un gossip protocol…

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. Et d'autre part tu sembles supposer que les choix fait par TCP sont applicables aux couches du dessus. 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.

Ta vision est envisageable dans des environnements très particuliers. Pas pour la majorité des systèmes.

Les piles tcp sont quand même vachement bien pensées pour ça !

Oui. Par contre t'as développé et gérés combien de systèmes au dessus de TCP en prod ? Tu serais surpris de ce qu'il se passe dans la vraie vie.

ou le redémarrage alors qu'on est déconnecté du réseau. Ça arrive si souvent que ça ?

Cf mon autre message. Tout les laptops sous linux qui ont une mise en veille pourrie et qui crash au resume ? Tout les laptops qui arrivent à cours de batterie ? Toutes les coupures de courant ? Avec des VM je suis sur qu'il y a des choses intéressantes aussi.

Oui la prod est pétée de sale truc et on a pas envie de gérer ces conneries à la main.

C'est un peu comme dire que TCP assure l'intégrité des messages et que t'as pas besoin de le faire niveau applicatif. La théorie te dit ok, la pratique te montre que des corruptions de segment alors que le checksum est valide ca arrive. La couche réseau n'est qu'une base pour monter un service. C'est un boulon.

Mhh… je ne comprends pas tout à fait cette remarque. J'ai déjà dit que normalement, on n'aurait pas besoin de keepalive dans un réseau « correct ».

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.

Le seul moyen qu'il garde la connexion, c'est que le programme reste actif. Et s'il reste actif, le keepalive ne changerait rien puisque justement, le programme continuerai de répondre à ses sollicitations !

Non:
- une machine qui crash
- Un arrêt brutal
- Un câble réseau débranché
- 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
- La liste peut être très longue

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.

Et t'es obligé d'être si agressif ? OK, c'est géré par la stack, méa culpa, mais c'est demandé par l'appli.

Je suis agressif ? Je suis juste factuel.

OK. Et donc, que me préconises-tu ? De relancer mon « contexte » à chaque fois que je me connecte ? Vive l'automatisation des tâches… Ou alors que j'utilise screen/tmux ? Ah mais alors, niveau ressources, c'est encore pire…

Je ne comprends pas que des mecs s'inquiètent des ressources en socket que pourraient bouffer un utilisateur à qui ils ont donné un shell sur une bécane. Je peux te bouffer des ressources de 50000 autres manières ! Pourquoi limiter artificiellement celle-là et pas les autres, alors qu'elle est si pratique ?!!

C'est une protection contre les leaks involontaires. Quand tu es en utilisation interactive tu veux que quand y'a un problème, ca garbage automatiquement, pas devoir revenir tuer tes shells, et les admins ne veulent pas non plus avoir à gérer ca. Quand tu es en utilisation batch, les utilisateurs savent qu'ils ont leurs processus en background a gérer puisqu'ils l'ont choisi. Dans ton les cas ton shell se termine.

Faut vraiment vivre à bisounours land pour penser que les utilisateurs reviennent tuer les processus quand une session interactive foire et qu'ils ont envi de s'amuser à retrouver les processus.

Moi, je n'ai pas de retour visuel quand une connexion déconne. Ça me fait chier.

Bien sur que si ton client SSH se termine avec un 255 comme exit value que se soit avec le TCP keepalive (bon la on est sur un temps de ~2h) ou le server alive.

Dans clientloop.c

Pour le server alive

static void
server_alive_check(void)
{
    if (packet_inc_alive_timeouts() > options.server_alive_count_max) {
        logit("Timeout, server %s not responding.", host);
        cleanup_exit(255);
    }
    packet_start(SSH2_MSG_GLOBAL_REQUEST);
    packet_put_cstring("keepalive@openssh.com");
    packet_put_char(1);     /* boolean: want reply */
    packet_send();
    /* Insert an empty placeholder to maintain ordering */
    client_register_global_confirm(NULL, NULL);
}

Pour le TCP keepalive

static void
client_process_net_input(fd_set *readset)
{
    int len, cont = 0;
    char buf[8192];

    /*
     * Read input from the server, and add any such data to the buffer of
     * the packet subsystem.
     */
    if (FD_ISSET(connection_in, readset)) {

    [...]

         if (len < 0) {
            /*
             * An error has encountered.  Perhaps there is a
             * network problem.
             */
            snprintf(buf, sizeof buf,
                "Read from remote host %.300s: %.100s\r\n",
                host, strerror(errno));
            buffer_append(&stderr_buffer, buf, strlen(buf));
            quit_pending = 1;
            return;
        }
        packet_process_incoming(buf, len);
    }

int
client_loop(int have_pty, int escape_char_arg, int ssh2_chan_id)
{
    while (!quit_pending) {
    [...]
        client_process_net_input(readset);

        if (quit_pending)
            break;
    [...]
    }
}

C'est tout l'intérêt du truc.

C'est facile de dire ça quand c'est une option par défaut. « Ferme-là, tu n'as rien à critiquer, le monde a décidé pour toi »

Oui c'est facile à dire quand le choix est pertinent et qu'en plus on peut le modifier.

En même temps quand tu cumuls le coût de la machine que tu vas dédier et le temps que tu vas passer, de trouver des pairs de confiance pour les MX secondaires etc., de la lutte pour avoir un serveur mail dans les plages ADSL, tu peux te permettre de te payer un hébergeur pour tes mails…

Après si tu veux le faire pour le fun c'est un choix. Mais si tu veux juste des mails qui fonctionnent nickels, choisir un prestataire sérieux c'est pas mal non plus.

Il est assez facile de designer un protocole ne prenant pas en compte la couche du dessous et de faire un truc qui rame plus qu'il ne devrait (hello HTTP !). Un exemple très simple est de tunneler du TCP dans du TCP. La gestion de congestion de TCP ayant été entièrement conçue en utilisant la perte de paquet, ça donne des résultats bien pourri par ce que la connexion tunnelée ne voit jamais de perte de paquet puisqu'elle est elle même dans un flux TCP. Tiens on peut ca avec SSH d'ailleurs ! Après je connais pas les détails sur ce sujet. Le fait de multiplexer plusieurs chanels dans une seule connexion TCP comme le fait SSH peut aussi poser des problèmes quand il y a des pertes de paquets, à chaque paquet perdu TCP prend ca pour une congestion et ralenti; tout les chanels multiplexés sont ralenti.

Un autre exemple concret avec SSH c'est qu'il effectue son propre flow control. Celui ci étant assez simpliste il bride complètement TCP (qu'on doit déjà configurer) sur des "long fat pipes", des liens au produit Bandwidth-delay élevé). Cf. http://www.psc.edu/networking/projects/hpn-ssh/

Bref c'est pas impossible, mais dans ce cas c'est intéressant d'avoir les références :p

Le hearbeat applicatif a exactement le même but que le keepalive tcp.

Dans l'idée oui. Maintenant le keepalive tcp ca sert absolument à rien tellement c'est pas configurable et adaptable aux besoins applicatifs. Donc tu te fais un truc qui marche et qui correspond exactement aux besoins de ton protocole. Ça part de ne rien faire du tout, jusqu'à faire des heartbeat bidirectionnels très agressifs dès que tu as un trou de trafic pour détecter tout problème dans la seconde.

WTF ? Et c'est quoi le keepalive TCP ou ssh d'après toi ?! C'est implémenté par l'appli ! Ça n'est pas du tout la stack TCP qui gère ça !

T'étais presque crédible sur ton couplet TCP-c-est-trop-génial-moi-j-ai-tout compris

sshd.c line 1796

      /* Set SO_KEEPALIVE if requested. */
        if (options.tcp_keep_alive && packet_connection_is_on_socket() &&
            setsockopt(sock_in, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) < 0)
                error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno));

http://tools.ietf.org/html/rfc1122#page-101

que les ressources bouffées par la mémorisation de ce genre d'empilement pourri est bien pire que garder une connexion TCP !

C'est pas tant que ca la connexion TCP qui bouffe de la ressource. Ce sont les données associée à la session et les processus.

En plus comme dit plus haut, d'un point de vue applicatif. Il doit y avoir plus de gens qui préfèrent voir visuellement que leur connexion est tombé (plutôt que d'attendre de taper quelque chose) que de gens comme toi. Dans tout les cas tu as le choix. T'as passé plus de temps sur ce journal qu'il t'en aurait fallu pour faire ta config.

TCP fonctionne comme ca et c'est pas plus mal qu'il laisse ca aux couches du dessus. À ce niveau t'as aucune idée des attentes de l'applicatif donc ce que tu vas faire tu vas le faire mal.

En fait c'est le TCP keep alive qui n'aurait pas du exister, il est assez bâtard et t'es toujours obliger de refaire un truc propre au niveau applicatif.

Oui enfin bon ta condescendances sur "TCP est prévu pour ca, les mecs d'OpenSSH sont des cons moi je sais ce qu'il faut faire" est pire.

Cette fonctionnalité de TCP c'est cool, le problème c'est que si tu n'émets pas de trafic, la connexion à une durée de vie illimitée et tu ne peux jamais libérer les ressources. Dans le monde réel ca pose comme un tout petit problème. Donc OpenSSH prend une très bonne approche, utiliser une configuration par défaut qui convient à 99% des configs (que leur réseau soit bon ou mauvais, ils ne veulent pas que ca leak) et fournissent une option pour ceux qui préfère l'autre comportement. En plus ils fournissent un heartbeat applicatif au dessus de TCP, qui est aussi nécessaire par ce que beaucoup de gens n'ont pas envie de devoir taper une commande pour se rendre compte que la connexion est tombée ou pour éviter de tomber dans la lenteur des timeouts TCP.

Bref les choix par défaut sont très raisonnables, et tu as toutes les options nécessaires pour faire ce que tu veux. Pourquoi venir pleurer pour qu'ils passent en mode "tire toi dans le pied" par défaut ?

http://www.potaroo.net/tools/ipv4/index.html

Après si tu vois pas le problème d'avoir 2³² adresses dispo dans un monde qui compte presque le double d'humains avec une tendance à aller de plus en plus vers plusieurs adresses IP par personnes. Maintenant comme toujours, plus la ressource va se faire rare plus ou va plus on va optimiser son utilisation, réparer les erreurs d'allocations du début d'Internet, et la faire tenir. Ca n'empêche pas qu'il y un problème.

Tu es donc soit chez Level 3 soit chez HP ;)

Cela dit ca veut rien dire, j'ai un /8 et c'est quand même NATé… C'est ca le luxe.

De plus, je regarde à long terme parce que ca me parait logique : le livret A est un produit d'epargne, pas un produit d'investissement (tiens, on en reviens à la discussion du début, et du coup ca me fait revenir la dessus : il y a bien une différence). En d'autres termes, les gens qui l'utilisent l'utilise pour "je met de l'argent ici, je l'aurai toujours dans 20 ans si j'en ai besoin", pas pour "je met de l'argent ici, ca va me rapporter X%".

L'épargne à plusieurs facettes non exclusives et tu ne veux en voir qu'une. Le Livret A est un produit comme un autre, qui est souvent combiné à d'autres qui présentent d'autres caractéristiques.

Les petits épargnants jouent souvent la sécurité, ils veulent juste mettre un peu de côté sans trop subir l'inflation (avec un Livret A on parle d'un an de smic qui rapporte max grosso modo 400 euros/an). Quand ton épargne augmente tu peux prendre d'autres options: sécurité, disponibilité, rendement potentiel. Ca n'en devient pas moins de l'épargne, le but est toujours de sacrifier ta consommation immédiate pour une consommation future. Les petits épargnants ne peuvent en général que combiner des produits très peu rémunérateurs mais sûrs avec des produits potentiellement rémunérateurs mais risqués. Les gros épargnants ont souvent en plus des options potentiellement rémunératrices et peu ou pas risquée.

Investir c'est épargner, il n'y a pas que l'épargne liquide dans la vie.

Sur les hébergeurs low cost tu as quand même un grosse différence entre DB et file system. Les mecs bourrent leurs machines autant que possible, du coup tu as un cache disque en RAM est misérable et tu as des perfs moisies. Les serveurs utilisés pour les DB sont un peu mieux loti et ca marche mieux.

Après si tu paies un poil plus cher chez un hébergeur correct, ca peut être envisageable. Mon hébergeur à 8Go de cache disque pour 16Go de RAM, ca peut être envisageable pour un working set pas trop gros.

Regardes les chiffres de révolution fiscale. Il faut monter plus haut que le salaire moyen/median des cadres pour que le taux d'imposition deviennent dégressif (et c'est ca le premier vrai problème qu'il faut corriger).

Après chaque cas est particulier en partant du célibataire mobile qui va se faire flinguer à 20% d'imposition jusqu'au mec qui va payer 0 euros par ce qu'il rentre dans plusieurs cases ou qu'il a les ressourcent pour investir beaucoup.

Un cadre ne gagne pas forcément 4.000€/mois : tu peux être cadre et être en-dessous des 2.000€/mois

Le revenu median des cadres est 42K net et 47K net pour le moyen. Pour un part et sans optimisation fiscale ca donne respectivement 13% et 15.2% (oui ca monte assez vite).

Quel est le rapport entre le plafond du livret A et l'épargne ?

Il est mal payé ton cadre pour être à 8%, ou alors il va dans les niches fiscales…

Plutôt que de balancer un 75% pour le symbole ça ne serait pas plus simple de virer les niches et optimisations fiscales et d'appliquer réellement le barème qui est censé exister ? Par ce que si tu arrives à gruger avec un taux marginal à 40% tu y arriveras aussi avec un à 75%… Donc c'est purement populiste comme démarche, mais ça paie de taper sur les riches en ce moment.

En général dans un concours on essai d'avoir des critères qui permettent d'ordonner les soumissions… Et en général on utilise ces critères pour développer sa solution et scorer au maximum. Comme dans la vraie vie.

Ce que tu énonces ça me semble juste être le bon sens pour qu'une soumission soit valide: Répondre à la question posée. Après comment tu juges les participations valides ? Au doigt mouillé ?

Le problème c'est peut être d'apprendre l'anglais alors ? Le jour où tu as à bosser avec une équipe en Chine, en Allemagne, en Inde, en Suède tu seras content qu'ils parlent anglais plutôt que dans leur langue.

Utiliser une langue commune c'est aussi pratique pour permettre de recruter différentes nationalités sans demander à tout les mecs d'être immédiatement trilingue.

Au sens ça ce démontre vraiment ?

http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Car par l'absurde, avec une approche de très bas niveau j'ai
Si je vois les mêmes donnée au même moment sur tous les nœuds qui fonctionnent, ça veut dire qu'ils sont synchronisé de manière instantanée, j'ai donc une violation de causalité CQFD.

Je pense qu'un peu de lecture sur les systèmes distribués pourraient t'être utile pour comprendre la discipline. Y'a de très bons bouquins et cours ;)

C'est une égalité de traitement.

Pour l'être humain, l'égalité est le principe qui fait que les hommes doivent être traités de la même manière, avec la même dignité, qu'ils disposent des mêmes droits et sont soumis aux mêmes devoirs.

J'espère que tu n'essayais pas quand même pas d'insinuer que les hommes sont égaux en capacité ?

Un photographe animalier, même s'il travail comme un dingue, aura une vie plus épanouie que le trimar quelconque (opérateur sur une chaîne, agent d'entretien, caissier de supermarché) pourquoi devrait-il gagner 10 fois plus ?

Peut être par ce que le mec va devoir passer 9 mois par an en déplacement pendant les 30 prochaines années ? Peut être par ce qu'il a réussi à décrocher sa place dans un environnement compétitif ? Peut être que des salariés dans ce domaine ça n'existe quasiment pas et que pour un qui réussi 100 se sont cassé la gueule sans aucune sécurité ? Bref des dizaines de critères subjectifs…

Le problème c'est qu'en dehors des beaux discours je ne connais pas de façon de objective de classer les métiers et de leur attribuer une valeur en fonction des différents critères possibles. Il est facile de constater les problèmes mais difficile de proposer une solution.

Tu dis donc toi même que tu mélanges tout. L'hypothèse de base était:

Entretenir la société nécessite une quantité de travaille fini, l'industrialisation à permis que cette quantité puisse être fournie par quelques hommes seulement. Où est passé ce gain de productivité ?

Aujourd'hui et jusqu'à une prochaine révolution, le travail nécessaire ça n'existe pas. N'importe quelle quantité de travail peut être absorbée. Les gains sur la productivité peuvent facilement être réaffecter à d'autres taches: produire plus, produire de nouvelles choses, produire de meilleur qualité, fournir de nouveaux services etc.

Le facteur déterminant de l'équilibre, et tu le dis toi même, c'est la valeur. L'équilibre actuel vient de la question infiniment complexe de la répartition de la valeur, mais probablement pas du fait qu'on a dépassé le travail nécessaire à entretenir la société. Change la répartition de la valeur et un nouvel équilibre se formera.