Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 9 PremièrePremière 123456789 DernièreDernière
Affichage des résultats 31 à 60 sur 262
  1. #31
    rendez-vous sous le gui pour en avoir le coeur net :P

  2. #32
    je ne fais que ça me documenter... c'est la base même de la connaissance.
    Par contre toi tu devrais me lire plus attentivement, je ne parle pas d'apocalypse, ni de la station mir (qui n'existe plus epuis quelques temps déjà), ni de tsunami...
    Par contre les messages postés disent globalement "ah non c'est impossible" plus par conviction profonde que par raisonnement logique.

    Bien sur cela parait improbable, ce qui ne veut pas dire que ce n'est pas faisable, mais bien le contraire.

    Il est tout aussi improbable que dans la même semaine, la bourse de tokyo soit obligé de fermer quelques heures à la suite d'un problème informatique majeur, tout comme la française des jeux.

    Ces 2 réseaux ne sont pas les moins sécurisés du monde, bien au contraire, pourtant ils ont connu une défaillance majeure.

    Et ce n'est pas les seuls réseaux d'importance à avoir connu des dysfonctionnements au cours des dernières semaines...

    Ces problèmes surviennent en fin d'années, au moment où pour des raisons comptables énormément de données vont circuler sur les différents réseaux... tout le monde était sur le qui vive le 31 décembre 1999, pou cause de risque de bug généralisé, mais aujourd'hui tout cela est du passé il n'y a pas eu de bug, la machine roule sans encombre...
    Mais si un groupe avait trouvé le moyen de généré un tel bug a partir de l'ajout d'une seconde intercallaire au temps universel, ceci n'etant qu'une hypothèse... comment s'y prendrait il?

    Libre a chacun de penser ce qu'il veut de cette hypothèse, vraie, fausse, impossible, improbable....

    N'empêche que lorsque je regarde mon horloge windows, et que je me penche sur la façon dont celle-ci marque les secondes, je constate que cette affichage n'est pas linéaire, que ceci n'est vrai que depuis quelques semaines, et que j'ai l'impression qu'on force cette horloge à prendre une seconde de retard.
    Si vous ne me croyez pas, alors c'est que votre propre horloge sous windows affiche l'heure de façon régulière, par contre cette hypothèse devient beaucoup plus crédible aux yeux de ceux qui vont constater comme moi que leur horloge n'affiche plus les secondes de façon linéaire...

    Faites le test, il est archi simple, et donnez moi vos inpressions, interprétations etc....

  3. #33
    Citation Envoyé par negundo
    je ne fais que ça me documenter... c'est la base même de la connaissance.
    Par contre toi tu devrais me lire plus attentivement, je ne parle pas d'apocalypse, ni de la station mir (qui n'existe plus epuis quelques temps déjà), ni de tsunami...
    Par contre les messages postés disent globalement "ah non c'est impossible" plus par conviction profonde que par raisonnement logique.

    Bien sur cela parait improbable, ce qui ne veut pas dire que ce n'est pas faisable, mais bien le contraire.

    Il est tout aussi improbable que dans la même semaine, la bourse de tokyo soit obligé de fermer quelques heures à la suite d'un problème informatique majeur, tout comme la française des jeux.

    Ces 2 réseaux ne sont pas les moins sécurisés du monde, bien au contraire, pourtant ils ont connu une défaillance majeure.

    Et ce n'est pas les seuls réseaux d'importance à avoir connu des dysfonctionnements au cours des dernières semaines...

    Ces problèmes surviennent en fin d'années, au moment où pour des raisons comptables énormément de données vont circuler sur les différents réseaux... tout le monde était sur le qui vive le 31 décembre 1999, pou cause de risque de bug généralisé, mais aujourd'hui tout cela est du passé il n'y a pas eu de bug, la machine roule sans encombre...
    Mais si un groupe avait trouvé le moyen de généré un tel bug a partir de l'ajout d'une seconde intercallaire au temps universel, ceci n'etant qu'une hypothèse... comment s'y prendrait il?

    Libre a chacun de penser ce qu'il veut de cette hypothèse, vraie, fausse, impossible, improbable....

    N'empêche que lorsque je regarde mon horloge windows, et que je me penche sur la façon dont celle-ci marque les secondes, je constate que cette affichage n'est pas linéaire, que ceci n'est vrai que depuis quelques semaines, et que j'ai l'impression qu'on force cette horloge à prendre une seconde de retard.
    Si vous ne me croyez pas, alors c'est que votre propre horloge sous windows affiche l'heure de façon régulière, par contre cette hypothèse devient beaucoup plus crédible aux yeux de ceux qui vont constater comme moi que leur horloge n'affiche plus les secondes de façon linéaire...

    Faites le test, il est archi simple, et donnez moi vos inpressions, interprétations etc....
    C'est pas moi qui part dans des délires. J'ai franchement du mal à voir à quoi ça sert de mettre une seconde de retard pour arriver à pirater des données, je vois pas le lien.

    Enfin moi dans un cas pareil je commencerais à vérifier ma machine, la pile du BIOS ...

    Et un réseau sécurisé, à ce point critique qui se fait pêter, c'est limite rassurant :D.

    Toi qui parlais de Cisco, je te signale qu'il y a de fortes chances que 95% du matos réseau de la Française des Jeux et de la bourse de Tokyo soit du Cisco, et vu les failles qui trainent dans l'IOS ... ça, ça me parait plus plausible, plutôt qu'un hypothétique décalage d'une seconde sur le temps universel pour provoquer une faille spatio-temporelle qui va aspirer la moitié de l'argent qui circule dans le monde.

    Si tu te documentais, comme tu le dis, t'aurais pas balancer une énormité comme l'heure forgée dans les datagrammes IP ....

  4. #34
    la pile du bios ne sert qu'a permettre le maintient d'une certaine tension dans la mémoire volatille du bios... si ma pile est morte je perds mes paramètres mais normalement cela ne doit affecter en rien la façon dont ma machine marque le temps qui passe sous la forme d'une seconde.

    La pile n'est utile que si l'ordinateur est débranché, car tant que cela n'est pas le cas, la carte mère reste sous tension il n'y a pas besoin de pile...

    SI tu enlèves la pile de sauvegarde du bios, que tu reparamètres ton ordi, il va fonctionner normalement, jusqu'à ce que tu le débranches du réseau électrique.
    enfin chez moi c'est comme cela que ça marche...

    Par contre tu ferais mieux de me demander si mon alimentation électrique est stabilisée...

    De toute façon, j'ai déjà vérifié ma pile avec un testeur, et cette pile n'a pas de problème, je n'élude jamais une hypothèse, même si celle ci me semble improbable, aussi je teste si oui ou non et je me fais mon opinion...

  5. #35
    Bon j'avoue que je force un peu la chose en jouant sur la notion de temps, mais un datagramme ip est bien horodaté non? la question est par rapport à quoi? quel est la référence ultime de temps auquel se réfère les différentes machines du réseau si ce n'est pas le temps universel délivré par les serveurs de temps...

    Concernant la structure d'un datagramme ip, ma doc perso la voici:

    La structure du datagramme est présentée par mots de 32 bits. La longueur minimale de l’en-tête est de 20 octets.

    * Mot 1 Version (4 bits), Longueur d'en-tête (4 bits), Type de service (8 bits), Longueur du paquet ou fragment (16 bits)
    * Mot 2 Identification (16 bits), Drapeau (3 bits), Déplacement de fragment (13 bits)
    * Mot 3 Durée de vie (8 bits), Protocole (8 bits), Contrôle de l'en-tête (16 bits)
    * Mot 4 Adresse IP source
    * Mot 5 Adresse IP destination
    * Mot 6 Optionnel : Options éventuelles(24 bits)
    * Données

    Différents champs de l'en-tête IP :

    Version : version d'IP, IP rejette tout datagramme avec une version non traitée.
    Longueur de l'en-tête : longueur de l'en-tête en mots de 32 bits, la taille minimale de l'en-tête est 20 octets.
    Type de service et priorités :
    Priorité de 0 (normale) à 7 (supervision réseau)
    Différents types de service (info au routage)

    D délai court (delay)
    T débit élevé (throughput)
    R fiabilité (reliability)
    C coût (lower cost)

    Le terme anglais employé pour type de service est TOS (type of service). Le support des types de service dépend du protocole de routage interne associé (RIP: hop count, OSPF: débit, délai, fiabilité).
    L'approche TOS distingue les différents critères: débit, délai, fiabilité, coût. Elle n'est pas adaptée aux supports de communications actuels. En fait, sur les supports optiques haut débits respectent tous ces critères simultanément. Rares sont les réseaux qui emploient différents critères, le critère le plus adapté est une fonction du débit et du délai.
    Longueur totale: taille du datagramme ou du fragment en octets (taille maximale: 65535 octets)
    Identification: attribué par la couche IP émetteur, distingue différentes sessions entre mêmes machines.
    Drapeau: deux bits contrôlent la fragmentation, l'un pour interdire la fragmentation d'un datagramme (ex: boot, Path MTU discovery), l'autre indique que le fragment n'est pas le dernier (fragment à suivre)
    Déplacement de fragment: place du fragment dans le datagramme pour un datagramme fragmenté, la taille du datagramme est obtenue à l’aide du dernier fragment en additionnant son déplacement multiplié par 8 à sa longueur. La taille minimale d'un fragment est donc de 8 octets.
    Durée de vie: nombre de sauts maximum possibles pour le fragment. Lors du transit, chaque routeur décrémente ce champs, le datagramme est éliminé si ce champ tombe à 0 et un message d'erreur (protocole ICMP) est renvoyé à l'émetteur initial du fragment.
    Protocole: protocole de niveau supérieur employé pour créer le message de la zone donnée (UDP, TCP, ICMP, EGP, OSPF, etc..), le principe est le même que pour le champ protocole de la trame Ethernet
    Total de contrôle de l'en-tête : le total de contrôle ne s'applique qu'à l'en-tête, ceci diminue le coût de traitement au niveau des routeurs, le contrôle d'erreur des données est confié aux protocoles de plus haut niveau. Ce champ est recalculé sur chaque routeur du fait de la modification du champ TTL. Le mode de calcul est une addition complément à un. De cette façon, le remplacement d’un élément passe par deux opérations (soustraction de l’ancien et addition du nouvel élément).
    Options : si elle existe, cette zone comporte trois champs: copie, classe d'option et numéro d'option. Le bit copie à 1 demande en cas de fragmentation la copie de l'option dans tous les fragments. Le champ classe d'option code les deux significations: 0 correspond à la classe datagramme ou supervision réseau, 2 correspond à la classe mise au point et mesures.
    Pour la classe 0, on remarque les numéros d'options suivants:
    restriction de sécurité et de gestion,
    routage lâche définit par la source,
    enregistrement de route,
    routage strict définit par la source.
    L'horodatage IP demande l'enregistrement des temps de passage du datagramme dans chaque routeur.
    La taille des options est limitée par la taille maximale de l'en-tête IP qui est de 64 octets. Les datagrammes avec options de proche en proche requièrent des traitements logiciels sur les routeurs, ils ne sont pas traités à la volée comme les datagrammes ordinaires.

  6. #36
    Citation Envoyé par negundo
    Bon j'avoue que je force un peu la chose en jouant sur la notion de temps, mais un datagramme ip est bien horodaté non? la question est par rapport à quoi? quel est la référence ultime de temps auquel se réfère les différentes machines du réseau si ce n'est pas le temps universel délivré par les serveurs de temps...

    Concernant la structure d'un datagramme ip, ma doc perso la voici:

    La structure du datagramme est présentée par mots de 32 bits. La longueur minimale de l’en-tête est de 20 octets.

    * Mot 1 Version (4 bits), Longueur d'en-tête (4 bits), Type de service (8 bits), Longueur du paquet ou fragment (16 bits)
    * Mot 2 Identification (16 bits), Drapeau (3 bits), Déplacement de fragment (13 bits)
    * Mot 3 Durée de vie (8 bits), Protocole (8 bits), Contrôle de l'en-tête (16 bits)
    * Mot 4 Adresse IP source
    * Mot 5 Adresse IP destination
    * Mot 6 Optionnel : Options éventuelles(24 bits)
    * Données

    Différents champs de l'en-tête IP :

    Version : version d'IP, IP rejette tout datagramme avec une version non traitée.
    Longueur de l'en-tête : longueur de l'en-tête en mots de 32 bits, la taille minimale de l'en-tête est 20 octets.
    Type de service et priorités :
    Priorité de 0 (normale) à 7 (supervision réseau)
    Différents types de service (info au routage)

    D délai court (delay)
    T débit élevé (throughput)
    R fiabilité (reliability)
    C coût (lower cost)

    Le terme anglais employé pour type de service est TOS (type of service). Le support des types de service dépend du protocole de routage interne associé (RIP: hop count, OSPF: débit, délai, fiabilité).
    L'approche TOS distingue les différents critères: débit, délai, fiabilité, coût. Elle n'est pas adaptée aux supports de communications actuels. En fait, sur les supports optiques haut débits respectent tous ces critères simultanément. Rares sont les réseaux qui emploient différents critères, le critère le plus adapté est une fonction du débit et du délai.
    Longueur totale: taille du datagramme ou du fragment en octets (taille maximale: 65535 octets)
    Identification: attribué par la couche IP émetteur, distingue différentes sessions entre mêmes machines.
    Drapeau: deux bits contrôlent la fragmentation, l'un pour interdire la fragmentation d'un datagramme (ex: boot, Path MTU discovery), l'autre indique que le fragment n'est pas le dernier (fragment à suivre)
    Déplacement de fragment: place du fragment dans le datagramme pour un datagramme fragmenté, la taille du datagramme est obtenue à l’aide du dernier fragment en additionnant son déplacement multiplié par 8 à sa longueur. La taille minimale d'un fragment est donc de 8 octets.
    Durée de vie: nombre de sauts maximum possibles pour le fragment. Lors du transit, chaque routeur décrémente ce champs, le datagramme est éliminé si ce champ tombe à 0 et un message d'erreur (protocole ICMP) est renvoyé à l'émetteur initial du fragment.
    Protocole: protocole de niveau supérieur employé pour créer le message de la zone donnée (UDP, TCP, ICMP, EGP, OSPF, etc..), le principe est le même que pour le champ protocole de la trame Ethernet
    Total de contrôle de l'en-tête : le total de contrôle ne s'applique qu'à l'en-tête, ceci diminue le coût de traitement au niveau des routeurs, le contrôle d'erreur des données est confié aux protocoles de plus haut niveau. Ce champ est recalculé sur chaque routeur du fait de la modification du champ TTL. Le mode de calcul est une addition complément à un. De cette façon, le remplacement d’un élément passe par deux opérations (soustraction de l’ancien et addition du nouvel élément).
    Options : si elle existe, cette zone comporte trois champs: copie, classe d'option et numéro d'option. Le bit copie à 1 demande en cas de fragmentation la copie de l'option dans tous les fragments. Le champ classe d'option code les deux significations: 0 correspond à la classe datagramme ou supervision réseau, 2 correspond à la classe mise au point et mesures.
    Pour la classe 0, on remarque les numéros d'options suivants:
    restriction de sécurité et de gestion,
    routage lâche définit par la source,
    enregistrement de route,
    routage strict définit par la source.
    L'horodatage IP demande l'enregistrement des temps de passage du datagramme dans chaque routeur.
    La taille des options est limitée par la taille maximale de l'en-tête IP qui est de 64 octets. Les datagrammes avec options de proche en proche requièrent des traitements logiciels sur les routeurs, ils ne sont pas traités à la volée comme les datagrammes ordinaires.
    Visiblement la coco est de bonne qualité cette année.

    Tu le sors d'où ton horodatage ?

    Non, un paquet IP n'est PAS horodaté.

  7. #37
    non, mais c'est tres bien ce que tu racontes, 'est ptetre possible, mais y a un quand même un gros raccourci, et je le dis depuis le début, c'est quoi le rapport entre les problèmes informatique a Tokyo, a la française des jeux et ceux de ton ordi ?

    parce que bon, c'est un méchant raccourci, quand même.

    et t'as pas répondu a la question, ton pc il est overclocké ?

    sinon, verifie que un programme en résident modifie pas l'heure, tout seul, hein, faut pas voir le mal partout.

  8. #38
    Citation Envoyé par negundo
    la pile du bios ne sert qu'a permettre le maintient d'une certaine tension dans la mémoire volatille du bios... si ma pile est morte je perds mes paramètres mais normalement cela ne doit affecter en rien la façon dont ma machine marque le temps qui passe sous la forme d'une seconde.

    La pile n'est utile que si l'ordinateur est débranché, car tant que cela n'est pas le cas, la carte mère reste sous tension il n'y a pas besoin de pile...

    SI tu enlèves la pile de sauvegarde du bios, que tu reparamètres ton ordi, il va fonctionner normalement, jusqu'à ce que tu le débranches du réseau électrique.
    enfin chez moi c'est comme cela que ça marche...

    Par contre tu ferais mieux de me demander si mon alimentation électrique est stabilisée...

    De toute façon, j'ai déjà vérifié ma pile avec un testeur, et cette pile n'a pas de problème, je n'élude jamais une hypothèse, même si celle ci me semble improbable, aussi je teste si oui ou non et je me fais mon opinion...
    Si je suggères, c'est bien que j'ai déjà été confronté au problème ... Une horloge qui se décale, à cause d'une pile fatiguée ...

  9. #39
    ça peut aussi être la carte mère qui a un problème ...

  10. #40
    cette carte mère est quasiment neuve, mais je te l'accorde cela pourrait être la source du problème, par contre j'ai le même problème sur mon ancien portable, un céléron 533. Celui ci est rarement connecté sur mon réseau ou sur internet je m'en sert que pour faire du texte, bref comme une machine à écrire.
    Je l'utilise pour éviter de me casser la tête, il est vieux, sa coque est très abimé, personne ne va me le voler. Je l'ai de nouveau connecté sur le net à la fin du mois de novembre, afin de relever des mails par le bias d'une connexion rtc chez free.
    Pour gérer mes mails, j'utilise thunderbird en version portable afin de les stocker sur ma clé usb... cela me permet de relever plusieurs comptes emails rapidement, et de garder un trace de toutes ma correspondance.

    Mais depuis ce jour là, mon portable a lui aussi des problèmes pour afficher l'heure... au début je pensais à un problème d'affichage de l'écran à matrice passive... mais comme ce problème survient aussi sur ma stationd de travail, j'ai des doutes...

  11. #41
    Bon en tout cas merci de réflechir avec moi au problème.
    Mon pc n'est pas overclocké, car j'ai besoin d'une grande stabilité dans mon travail, et j'ai la puissance nécessaire pour ne pas avoir besoin de monter en puissance par le biais de l'overcloking.
    Je fais principalement de la vidéo numérique, et j'aime bien que ma machine soit le plus stable possible, histoire de ne pas perdre des heures de travail en ayant gagné 0,01% de puissance de calcul.

    Concernant ma machine c'est un pentium 640 (d'ailleurs à ce propos si j'utilise PC wizard il indique pentium 641 (estimé), je ne savais pas qu'intel faisait de pentium 641 d'ailleurs je suis certain que non, et en utilisant cpu-Z je retrouve mon P4 640)
    Ma carte mère est une Gigabyte GA-8I955X Royal basée sur le chipset intel 955X.
    mémoire, disques durs etc... aucun problème signalé, le bios de ma CM est à jour depuis hier par le biais de la version 7.

  12. #42
    visiblement lire plus de 2 lignes de texte pose problème à certains.... mais si tu n'arrives pas à trouver le terme horodatage dans la description de la structure d'une en tête d'ip, utilise la fonction de recherche automatique disponible sur ton navigateur... avec un peu de chance il va même te surligner le mot...

    Ensuite si la ttl n'a rien avoir avec le temps qui passe c'est que je n'ai décidément rien compris du tout à la notion de durée de vie

  13. #43
    TTL est en fait le nombre maximal de routeurs que peut traverser le paquet avant d'etre détruit. Donc rien a voir avec un temps.

    http://www.commentcamarche.net/internet/protip.php3
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  14. #44
    d'ailleur au passage la notion de paquet fantome à durée de vie infinie est elle impossible?

    surtout si on imagine que certains routeurs en calculant la nouvelle durée de vie du paquet tombe exactement sur la même que celle de départ....

    Un routeur traite un datagramme, il va modifer le champ durée de vie, mais cette modification donne le même champ.... voilà la génése d'un datagramme ip qui ne pourra peut être jamais mourir et se balader sans fin sur le réseau.

    Si ce datagramme à une priorité= 7, alors il est prioritaire sur tous les autres, et va passer par les plus grosses fibres optiques disponibles, celle des gros opérateurs de télecommunication... comme AT&T, FT etc...

    Si son IP de destination n'est pas attribué il va tourner en boucle de réseau en réseau, et il ne sortira que lorsque que cet ip est attribué...

  15. #45
    Le champ TTL sert à éviter ca. A chaque passage dans un routeur le ttl est décrémenté quand il arrive a 0 le routeur le jette. Meme si un routeur fait une connerie, il y a peu de chance pour que les autres fassent la meme. Donc non un paquet IP ne peut pas circuler indéfiniment sur le réseau.
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  16. #46
    tu me dis que la notion TTL soit temps à vivre (time to live) est étrangère à la notion de temps alors que le terme même indique le contraire...

    Bergson a raison en disant que le temps n'existe pas en soit mais qu'il existe en toute chose... maintenant appliqué à l'informatique en réseau cela devient fort compliqué à comprendre...

  17. #47
    Bon écoute mon prof de réseau m'a dit ce que je viens de te dire ainsi que d'autres sites. Alors a moins d'une conspiration des chinois du FBI, moi je pense que c'est ca. Dis-toi aussi que de coder une date ou un temps d'ordre de grandeur réseau sur 8 bits ben ce te fait pas beaucoup de temps a vivre.
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  18. #48
    Citation Envoyé par negundo
    Durée de vie: nombre de sauts maximum possibles pour le fragment. Lors du transit, chaque routeur décrémente ce champs, le datagramme est éliminé si ce champ tombe à 0 et un message d'erreur (protocole ICMP) est renvoyé à l'émetteur initial du fragment.
    T'as bien lu ta doc ?
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  19. #49
    et je sais que sur certains réseaux il existe des paquets fantômes, qu'il existe aussi des processus fantômes au sein d'un cpu etc...

    un lien au passage:

    http://abcdrfc.free.fr/rfc-vf/rfc793.html

  20. #50
    On parle du protocole IP la pas de TCP.

    je cite ton lien "Comme la durée de vie d'un paquet dans le réseau ne peut excéder quelques dizaines de secondes"
    "si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
    If all goes well will Dell sell Cells?
    <°)))><

  21. #51
    Citation Envoyé par negundo
    d'ailleur au passage la notion de paquet fantome à durée de vie infinie est elle impossible?
    à l'université de tours, service info & réseaux, où j'ai bossé cet été, on m'a dit qu'anecdotiquement ça arrivais de voir dfes paquets IP buggués se balader, datant des débuts d'internet, donc je suppose que non, ça n'est pas censé exister.

  22. #52
    oui j'ai bien lu la doc, mais je me emande qu'est ce qui se passerait si quelqu'un avait trouver le moyen de corrompre certains routeurs cisco, de façon a ce qu'ils ne puissent plus enlever 1 au champ TTL....
    Je réfléchie dans cette direction, en imaginant une solution basée sur l'architecture x86, et obligeant cette architecture à "oublier" certain cycle d'horloge afin de faire prendre à la machine une seconde de retard toute les 60 secondes par exemple, j'iamgine qu' à la 61 secondes la machine infecté se synchronise sur un serveur temps, ainsi elle est tojours à l'heure, sauf durant 1 seconde chaque minute...
    C'est très théorique, je me demande juste comment procéder, c'est pour ela que je poste sur ce forum, auprès de ceux qui connaissent bien cette architecture, la notion de cycle d'horloge etc....

  23. #53
    Citation Envoyé par negundo
    le temps (et donc l'heure...) n'est pas pris en compte dans un datagramme ip...

    Je croyais que dans la structure d'un datagramme ip il existait par exemple un champ priorité, et que des paquets dont ce champ=7 passent devant tout le monde sur le réseau, du moins pour les routeurs qui tiennent compte de ce codage...

    Mais de toute façon mon hypothèse n'est que science fiction je ne cesse de le répéter, elle n'est pas vrai, c'est juste une base de départ pour une réflexion autours de la notion de temps
    Oui, ca existe, c'est justement ce dont j'ai parlé avec mon post precedent. Ca s'apelle justement le QoS, ou Quality of Service.
    Un homme rentre dans un café =>PLOUF !

  24. #54
    Citation Envoyé par negundo
    tu me dis que la notion TTL soit temps à vivre (time to live) est étrangère à la notion de temps alors que le terme même indique le contraire...

    Bergson a raison en disant que le temps n'existe pas en soit mais qu'il existe en toute chose... maintenant appliqué à l'informatique en réseau cela devient fort compliqué à comprendre...
    Faut savoir séparer les notions, la notion de temps selon bergson est complètement distincte de la notion de TTL. Comme on vient de te l'expliquer 50 fois, le TTL c'est le nombre de routeur que le paquet peut traverser avant d'être détruit, pas une durée abstraite formée par l'Homme et qui lui sert à se repérer dans l'espace temporel.

  25. #55
    Citation Envoyé par negundo
    et je sais que sur certains réseaux il existe des paquets fantômes, qu'il existe aussi des processus fantômes au sein d'un cpu etc...

    un lien au passage:

    http://abcdrfc.free.fr/rfc-vf/rfc793.html
    Y'en a aussi qui ont des fantômes encéphaliques

  26. #56
    Citation Envoyé par negundo
    oui j'ai bien lu la doc, mais je me emande qu'est ce qui se passerait si quelqu'un avait trouver le moyen de corrompre certains routeurs cisco, de façon a ce qu'ils ne puissent plus enlever 1 au champ TTL....
    Je réfléchie dans cette direction, en imaginant une solution basée sur l'architecture x86, et obligeant cette architecture à "oublier" certain cycle d'horloge afin de faire prendre à la machine une seconde de retard toute les 60 secondes par exemple, j'iamgine qu' à la 61 secondes la machine infecté se synchronise sur un serveur temps, ainsi elle est tojours à l'heure, sauf durant 1 seconde chaque minute...
    C'est très théorique, je me demande juste comment procéder, c'est pour ela que je poste sur ce forum, auprès de ceux qui connaissent bien cette architecture, la notion de cycle d'horloge etc....
    Très certainement un engorgement du réseau, tout simplement ...

  27. #57
    anecdotes: des paquets ip envoyés au tout début d'internet font surface de manière aléatoire aujourd'hui encore, ils ont donc une ttl infinie...

    Mais comme cela n'est pas possible alors ces paquets n'existent pas, malgrès le fait qu'ils soient une réalité quantifiable et vérifiable... où est l'erreur: dans la théorie ou dans la réalité? probablement plus dans la théorie que dans la réalité... ou alors je n'ai aussi rien compris à la démarche scientifique.

  28. #58
    Citation Envoyé par negundo
    anecdotes: des paquets ip envoyés au tout début d'internet font surface de manière aléatoire aujourd'hui encore, ils ont donc une ttl infinie...

    Mais comme cela n'est pas possible alors ces paquets n'existent pas, malgrès le fait qu'ils soient une réalité quantifiable et vérifiable... où est l'erreur: dans la théorie ou dans la réalité? probablement plus dans la théorie que dans la réalité... ou alors je n'ai aussi rien compris à la démarche scientifique.
    paquets BUGGÉS. Donc oui ils sont présents et existent. ... y'a pas une quelconque magie là dessous.

  29. #59
    il faut savoir séparer les notions de temps, de distance etc.. je suis entièrement d'accord sauf que c'est pas moi qui est décider de créer un lien entre toutes ces notions...
    personne ne voulaient lier ces notions il n'y a pas si longtemps sauf un homme qui travaillait en suisse, et qui était polytechnicien... il travaillait en suisse pour un organisme de certification.
    Son boulot n'était pas d'inventer des choses, mais d'établir des normes, en fait il ne les établissait même pas il était juste charger de vérifier si ces normes étaient cohérentes en fonction des lois de la physique.
    Il du se pencher sur le problème de l'unification du temps, problème qui se posait en Allemagne, nouvel état et qui cherhchait à harmoniser l'heure sur son territoire afin d'avoir un chemin de fer ponctuel...
    Sa situation personnel n'était pas brillante, il etait persuadé que sa place était du coté des grands de ce monde, Newton, Galilé, Planck etc... aussi cherchait il le moyen de faire une synthèse des anciennes découvertes dans le but de donner au monde une nouvelle théorie...
    son axe de réflexion fut le temps et l'onde... au bou de quelques temps il emis une hypothèse fort contesté et qui passa inapercu sauf pour une personne dont le renom scientifique était déjà assuré depuis longtemps...

    De là les sciences modernes, liant l'espace et le temps, dans un espace à 4 dimensions: hauteur, longueur, profondeur et temps
    ce lien permet de postuler une équivalence entre energie et matière, entre abstrait et concret, entre la réalité et l'imaginaire, et tout cela en disant que le temps est relatif...
    Mais pourquoi choisir le temps plutot que les distances par exemple...

  30. #60
    j'ai pris mon courage à 2 mains pour tout lire :whistle: et la premiere reaction que j'ai eu à la fin de ma lecture : c'est pas possible, c'est un troll.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •