( J'ai fais réseaux et télécoms, l'osi n'a plus de secret pour moi ! )

Bonjour !

Je reprend ici une discussion avec nohar.

• Struct avec un pack permet de " standardisé " l'information pour permettre une réception régulière de l'information ?

    Je dis bien réception car en télécoms, il ne faut pas oublier que deux appareils distants d'un équipement ne vont pas envoyer en même temps une information. Les protocoles  se basent sur des fenêtres de disponibilités avec des temps randoms d'attente. ( Bref. voir les protocoles sans fil en détail pour comprendre. )

    De plus il y a une variable qui fixe la fréquence d'émission de l'informations pour lutter contre la distance des appareils pour lutter encore contre le temps de propagation de l'information. Ainsi les appareils vont se synchro pour que les réceptions soient équitables entre eux, ce qui explique pourquoi en wifi, le débit disponible réduit avec le nombre de personne active sur le réseaux, pour devenir égale sauf règle de QoS.

Dans le cas de java, je sais que l'information peut être envoyer facilement dans des " sockets ". J'image qu'en python nous allons donc utiliser struct, faire des sockets pour les clients. Mais du coup doit on synchroniser les clients comme le fait le protocole wifi, où tout peut venir à la volé?

" T'as qu'à chercher !! "

Je pense qu'il est bon de me faire raisonner sur le sujet, avec de me lancer bêtement dans un cours. Je dis toujours qu'il faut lire la documentation, c'est ce que je ferai. Mais avant , je voudrai trouver par moi même les grands principes du fonctionnement d'une application réseaux en python.

Dans le cas de java, je sais que l'information peut être envoyer facilement dans des " sockets ". J'image qu'en python nous allons donc utiliser struct, faire des sockets pour les clients. Mais du coup doit on synchroniser les clients comme le fait le protocole wifi, où tout peut venir à la volé?

Je pense qu'il faut que tu te détaches des télécoms et que tu te places dans un référentiel beaucoup plus rigolo : celui des réseaux IP.

Une socket est une abstraction pour un flux de données. La plupart du temps, sur le réseau, on utilise des sockets TCP ou UDP. L'un comme l'autre sont deux protocoles qui sont utilisés au-dessus de IP (on parle bien de TCP/IP -- TCP over IP -- pour le réseau internet). En gros, la donnée est envoyée et routée sur le réseau grâce au protocole IP, puis une fois le paquet arrivé à la bonne machine, le protocole TCP va s'assurer que tous les paquets ont bien été reçus sans être corrompus. Du coup, ça peut passer par de la fibre, par du wifi, du bluetooth, de la 3G, des câbles ethernet, ou même tous à la fois : en tant que dev, on s'en fout, ça ne change rien puisque c'est la couche d'encapsulation en-dessous de IP qui va s'occuper des détails de synchronisation/timing/etc..

C'est le principe d’acquittement, j'en ai mangé, que celui de l'encapsulation et des couches Réseaux (OSI).

Mais c'est bon de le rappeler, surtout pour les gens qui nous lisent alors qu'ils n'y connaissent rien.

Preuve que j'ai atteint les limites de l'enseignement français, j'ai appris dernièrement à un prof que l'on pouvait avoir plusieurs clients sur une même socket, on m'a regardé avec des gros yeux pourtant mon code marchait bien et je ne suis pas le seul à le faire. Question de bon sens.

Sinon :

En effet, c'est la couche transport qui va effectuer la vérification des informations ( à prendre avec des pincettes ).

Nous agissons donc uniquement sur la donnée.

La fréquence de synchronisation entre client et serveur n'a donc pas besoin d'être géré. On rentre alors le fameux latence.

Fais tu partie de vielle école qui regroupe application, présentation, session en une seule ?

Savais tu que WiFi a ses trames considérées comme ethernet ? Ainsi, si on ne met pas en place certains protocoles réseaux, on peut  être totalement inaperçue dans un réseaux filaire en étant en wifi.

-
Edité par MonsieurVaros 16 mai 2014 à 16:31:28

Fais tu partie de vielle école qui regroupe application, présentation, session en une seule ?

Non c'est juste qu'il y a deux "modèles" pour les réseaux : OSI et TCP/IP. Le second modèle fusionne les trois dernières couches du modèle OSI, et à vrai dire ce n'est pas vraiment dérangeant puisque dans la réalité les limites entre ces trois couches sont vraiment très floues. Par exemple, les websockets (les "sockets over HTTP"), tu les collerais dans quelle couche ? Je suis partisan de m'économiser un doliprane et de considérer que c'est un protocole applicatif, point barre.

-
Edité par nohar 16 mai 2014 à 16:55:26

Sans vouloir être méchant, MonsieurVaros, tu me fais penser à Michel Riguidel : une bonne partie de ce que tu dis est relativement vrai, mais l'ensemble, en fait...

Je crois que si tu veux te lancer dans la programmation réseau, il va falloir commencer par tout remettre à plat.

MonsieurVaros a écrit:

[...]

En effet, c'est la couche transport qui va effectuer la vérification des informations ( à prendre avec des pincettes ).

[...]

-
Edité par MonsieurVaros il y a environ 8 heures

 MonsieurVaros a écrit:

[...]

Savais tu que WiFi a ses trames considérées comme ethernet ? Ainsi, si on ne met pas en place certains protocoles réseaux, on peut  être totalement inaperçue dans un réseaux filaire en étant en wifi.

Le Wifi (IEEE 802.3) s'applique sur les couches 1 et 2 du modèle OSI, comme l'Ethernet (IEEE 802.3), donc non tu ne peux pas de manière "simple" placer du wifi dans ton réseau ethernet. Il te faut passer par des bridges ou des AP.

De toute façon quand tu agis au niveau IP (couche 3/4), bah tu te fous royalement des couches 1 et 2 tant qu'elles font leur boulot.

Regarde sur un PC, que tu sois en Wifi ou en Ethernet et que tu as une adresse IP, ton programme avec tes sockets fonctionnera (sauf cas particulier).

 Bref je rejoins Erd.

Bon, histoire de ne pas passer pour le méchant connard de service, je vais mettre de côté mon aversion pour l'ecriture de longs messages avec cet éditeur et tenter d'expliquer le pourquoi du comment. Ça va être du bon gros résumé vulgarisé pas tout à fait juste. Mais on touche à pas mal de trucs un peu cossus, alors si je veux rester compréhensible...

MonsieurVaros a écrit: >( J'ai fais réseaux et télécoms, l'osi n'a plus de secret pour moi ! )

Le modèle OSI est un modèle théorique pour le réseau où il n'est que très rarement respecté. Il en existe d'autres plus intéressants comme TCP/IP que tu devrais étudier. En telecoms, il a été oublié depuis très longtemps.

>Je dis bien réception car en télécoms, il ne faut pas oublier que deux appareils distants d'un équipement ne vont pas envoyer en même temps une information.

Et pourquoi pas ? Surtout en télécommunications où les ressources sont allouées de bout en bout en cas d'utilisation du mode circuit. En réseau, c'est aussi possible si justement les appareils ne partagent pas le même ether (ie le même domaine de collision, par exemple).

>Les protocoles  se basent sur des fenêtres de disponibilités avec des temps randoms d'attente. ( Bref. voir les protocoles sans fil en détail pour comprendre. )

Pas toujours. C'est vrai pour des techniques d'accès comme le TDMA qui découpe les communications en timeslots (chacun émet à son tour pendant un laps de temps) mais pas pour des techniques comme le FDMA où on répartit non plus en temps mais en fréquences.

Si tu voulais parler des techniques comme le CSMA/CD/CA etc. ce n'est pas du tout inhérent au sans fil. Bien au contraire...

De plus il y a une variable qui fixe la fréquence d'émission de l'informations pour lutter contre la distance des appareils pour lutter encore contre le temps de propagation de l'information.

Pas compris ce que tu entends par variable... Mais la synchro se fait par un signal d'horloge sur lequel on vient se caler. Mais de toute manière, la synchro n'est pas forcément assurée car un signal radio va être répété à cause des réverbérations sur la matière mais avec un déphasage induit par le temps de propagation. Qui plus est, elle ne permet pas de lutter contre la distance : la latence ne peut être  modifiée.

Ainsi les appareils vont se synchro pour que les réceptions soient équitables entre eux, ce qui explique pourquoi en wifi, le débit disponible réduit avec le nombre de personne active sur le réseaux, pour devenir égale sauf règle de QoS.

Absolument pas. Le débit est fonction des ressources comme la bande passante. La synchro ne joue pas du tout sur la répartition du débit. En wifi, par exemple, on utilise majoritairement l'étalement de spectre par saut de fréquence. En gros, on alloue des timeslots sur plusieurs porteuses et les appareils passent d'une fréquence à l'autre selon un code donné. Ce qui crée ce qu'on appelle des canaux. Plus tu as de canaux alloués, plus tu auras de débits. En temps normal, les canaux sont répartis selon les usages et les capacités.

>Dans le cas de java, je sais que l'information peut être envoyer facilement dans des " sockets ". J'image qu'en python nous allons donc utiliser struct, faire des sockets pour les clients. Mais du coup doit on synchroniser les clients comme le fait le protocole wifi, où tout peut venir à la volé?

La synchro est gérée par la couche physique.

MonsieurVaros a écrit: >Preuve que j'ai atteint les limites de l'enseignement français, j'ai appris dernièrement à un prof que l'on pouvait avoir plusieurs clients sur une même socket

Tout dépend ce que tu entends par plusieurs clients sur une même socket. Si tu penses à des clients distants, effectivement c'est possible avec un protocole non connecté comme UDP (TCP ne permet pas plusieurs communications simultanées sur un même port. Les connexions sont donc redirigées vers de nouvelles sockets. C'est ce que fait un serveur web, par exemple.).

Si tu penses à plusieurs processus sur une même socket, ce n'est pas possible. Le noyau alloue une socket unique au processus. Quand bien même tu tricherais en utilisant un mécanisme comme une mémoire partagée (admettons), ce n'est absolument pas une bonne pratique : une socket identifie une application.

En effet, c'est la couche transport qui va effectuer la vérification des informations ( à prendre avec des pincettes ).

Chaque couche vérifie ses données généralement. Mais en tout cas, elle ne vérifie pas les données des autres.

>La fréquence de synchronisation entre client et serveur n'a donc pas besoin d'être géré. On rentre alors le fameux latence.

Ça ne veut strictement rien dire. La latence est le délai de transmission entre l'emission et la réception induit par le temps de propagation dans l'ether et de traitement par les noeuds intermédiaires comme les routeurs.

>Fais tu partie de vielle école qui regroupe application, présentation, session en une seule ? Ce n'est pas une vieille école. C'est la principale méthode et très souvent la seule envisageable. Le modèle OSI est théorique et peu réaliste.

>Savais tu que WiFi a ses trames considérées comme ethernet ? Ainsi, si on ne met pas en place certains protocoles réseaux, on peut  être totalement inaperçue dans un réseaux filaire en étant en wifi.

ZeqL a déjà expliqué tout ça. Mais oui, tu peux utiliser n'importe quel protocole sur n'importe quelle couche. Tu peux même créer ton propre protocole. Mais tu seras limité au premier équipement réseau qui ne comprendra pas ta trame et tu ne passeras pas du tout inaperçu. Pour peu que ton réseau soit sécurisé, tu seras tout de suite détecté...

"( J'ai fais réseaux et télécoms, l'osi n'a plus de secret pour moi ! )"

Je crois qu'il manque la partie modestie

Il faudra l'apprendre aussi (je parle de la modestie), car si tu n'apprends pas des autres, tu progresseras difficilement...

On a toujours plus cultivé que soit dans la vie, le forum peut être un formidable atout si on a une discussion en adéquation avec l'apprentissage.

Certes que tu es des connaissances, je ne le renie pas, qu'on soit bien d'accord, mais ne te fermes pas !

"je voudrai trouver par moi même les grands principes du fonctionnement d'une application réseaux en python."

Avant les grands principes d'une application réseau en python, si tu connais les grands principes d'une application réseau tout court, quelle est la difficulté de transcrire ces connaissances en python?