UDP, TCP, FTP, HTTP, Lib NetWork, Lib FTP, ....

[TO7]

Bonjour

Je pensais avoir compris a peu pres tous ces mots, mais je doit reconnaitre que en fait ça se melange un peu dernierement.

Je vais dire ce que j'ai compris, et si une bonne ame pouvait confirmer ou infirmer mes dires, cela me permettrais de solidifier un peu mes connaisances dans le domaine du reseau.

Le TCP et l'UDP sont deux protocoles de tranfert de données réseau, le premier possede une verification des données transmises et le second non.

Le HTTP est le protocole de communication de pages internet
Le FTP est un protocole de transfert de fichiers.

Bon jusque la je pense avoir un peu compris, c'est lorsque je l'utilise avec PB que je me melange un peu les idées.

La lib Network utilise apparement le TCP/IP, d'apres ce qu'en dit la doc.
La lib FTP utilise t'elle aussi le TCP/IP ???

Car lorsque je fait un OpenNetworkConnection(NomServeur$, Port) avec le port 80 (port par defaut du HTTP) sur une seconde machine sur laquelle j'ai installé APACHE, cela me repond que la connection est etablie.
Et lorsque je change sur la meme machine ou j'ai aussi installé Tysoft FTP, ce port par 21 (port par defaut du FTP) ça marche aussi

Et une autre question me trotte dans la tete, quand on créé un reseau windows sur sa machine, avec les favoris reseau et tout le bazard, c'est aussi du TCP/IP ??? car pour l'adresse je suppose que c'est LOCALHOST ou 127.0.0.1, mais quel est le numero de port dans ce cas ????

Merci de vos eclaircissements

[GallyHC]

Bonjour,

D'apres mes souvenir le TCP-IP est la pile de protocol (en gros c les trame qui passe sur un reseau) apres que ce soit FTP, HTTP, ect... c'est une couche de protocol (HTTP port 80, ect...), mais tout passe par TCP-IP.

Voila en gros je suis pas sur etre claire.

Cordialement,
GallyHC

[TO7]

Merci de cette reponse rapide.
Bon d'accord, donc tout est TCP/IP....
Et pour le reseau privé, network de windows, quel est le port, il doit bien en avoir un non ???
Car on indique le nom de la machine a connecter, mais jamais le port ...

[Backup]

.................

[Cls]

Il faut voir TCP/IP comme un empilement de couches que divers protocoles utilisent. TCP/IP s'appuie sur la modélisation OSI (qui contient 7 couches, alors que TCP/IP n'en contient que 4). Chaque couche utilise les services de la couche inférieure en lui transmettant ses données. La couche n°1 est logiquement le support physique (câbles, ondes, etc.).

La notion de "port" d'écoute que tu touches du doigt apparaît uniquement à la couche n°4 du modèle OSI (couche n°3 de TCP/IP il me semble mais à vérifier). Le réseau privé que tu cites se place à la couche 3 de l'OSI (1 ou 2 de TCP/IP), il n'y a donc pas de notions de ports.

La notion de ports est introduite dès lors qu'on fait discuter plusieurs services sur une même machine. Et c'est logique, comment pourrait - on savoir à quelle application la couche transport (de carte réseau à carte réseau) doit envoyer ses données sans utiliser cette notion ?

Edit : pour compléter mon post, je vais donner un exemple : une requête Web. Quand tu cliques sur un lien HTML, ton navigateur va construire une requête HTTP (car Internet est basé sur le protocole HTTP). Une fois construite, il va transmettre cette requête à une couche inférieure qui va se charger de se connecter au serveur et d’exécuter la demande. Cette couche, que l'on peut appeler "Transport" va se charger d'encapsuler cette requête HTTP dans une trame TCP, protocole permettant d'échanger des données sans risque de perte ou d'altération. TCP va ensuite transmettre ses données à IP qui, lui, va se charger de faire arriver notre paquet TCP à destination à travers Internet (on arrive sur la couche "Internet"). Pour se faire IP va donner son paquet de données à ta carte réseau (on arrive là, sur la couche Liaison). Elle même, va utiliser le câble qui relie ton poste à ton MODEM pour transmettre vers ton FAI.... Notre requête est enfin arrivée sur le réseau !

Une fois notre petite requête routée sur le réseau et arrivée à destination selon tout un tas de mécanisme divers et complexes, l'exacte opération inverse va s'opérer sur le poste client (poste, terminal, serveur, imprimante, etc.). Le câble envoi son signal à la carte réseau, elle - même va analyser le paquet IP. IP envoi vers TCP. TCP va envoyer ses données vers l'application correspondant au port spécifié, dans notre cas de requête Web le port 80 : serveur Apache. Notre serveur Apache va alors décoder la requête et envoyer une réponse exactement selon le même principe. La boucle est bouclée !

[TO7]

Merci à tous pour vos éclaircissements

@Dobro
Merci pour le lien, bien utile pour savoir a quelle porte sonner

@Cls
Et bien....je savais vaguement que le réseau c'était compliqué, on viens d'en faire la preuve je crois.
Quand je pense que dans quelques années toutes les applications seront sous ces protocoles et les langages du web, on a pas fini de se tirer les cheveux.

Donc pour récapituler, pas de port pour le réseau interne, mais il utilise quand même le TCP/IP comme les autres et comme l'a dit GallyHC
Donc en théorie avec OpenNetworkConnection(), je peux parler a un serveur FTP, un serveur HTTP, et même a mon réseau local, car cette fonction est basé sur le TCP/IP.

protocole permettant d'échanger des données sans risque de perte ou d'altération

Je pense que j'ai été trop prudent sur un de mes codes, je veux être certain que mes données arrivent au serveur
Alors le client envoie les données, j'attends que le serveur lui renvoie la longueur des données reçues
Le client reçois cette longueur et la compare a celle qu'il avait envoyé
Si c'est la même, il envoie la suite, sinon, il affiche que des données ont été perdues

Vu que ce transfert est déjà protégé, peut être ai je doublé une sécurité non nécessaire, et de ce fait, ralenti inutilement mes transferts ????

[Cls]

Disons que normalement TCP propose ce service. Maintenant tu peux ajouter une vérification en plus si tes données sont sensibles. Pour cela, mieux vaut utiliser un CRC (code à redondance cyclique) plutôt que la longueur des données reçues. Il arrive en effet fréquemment qu'un bit soit altéré et que les données ne changent pas de longueur.

Quant à parler directement à ton réseau local, tout dépend de ce que tu veux faire.... OpenNetworkConnection peut ne t'être d'aucun utilité si tu veux faire des traitements "bas niveaux".

[TO7]

OpenNetworkConnection peut ne t'être d'aucun utilité si tu veux faire des traitements "bas niveaux".

Non disons que c'était juste pour être sur que tout ce qui est transfert par le réseau est le plus fréquemment fait en TCP, même le réseau privé

Pour cela, mieux vaut utiliser un CRC

Je voyais a peu pres de quoi tu parles, mais pour etre sur je suis allé voir sur WIKIPEDIA qui propose meme un code en C pour ce genre de controle
http://fr.wikipedia.org/wiki/Contr%C3%B ... e_cyclique
En fait c'est un peu comme si on codait en MD5 coté client, puis on envoie les données, et le serveur renvoie le MD5 que l'on compare a celui du client

[Cls]

Oui c'est tout à fait ça. La différence entre les 2 est que le CRC permet de détecter et corriger les erreurs d'altération des données (que ce soit dû à un transfert réseau ou à un mauvais support physique), alors que le MD5 permet de générer un hash unique des données. Leurs applications sont complètement différentes. Théoriquement il n'est pas possible de retrouver la donnée originelle à partir du hash, c'est pourquoi le MD5 était fréquemment utilisé pour vérifier les mots de passe. Depuis quelques années, le MD5 n'est plus considéré comme sûr (rainbow tables, collisions de MD5), mieux vaut utiliser du SHA1.

[TO7]

Merci beaucoup CLS de tes explications plus que précises
Je commence un peu a m'y retrouver dans cette jungle...

Il n'est quand même pas exclu qu'une nouvelle question germe dans mon esprit d'ici quelques jours
Bonne soirée

[Cls]

C'est un plaisir, n'hésites pas.