Discussion :

[chacal]

Bonjour,

je n'arrive pas a comprendre l'utilite de la fonction bind().

Le role de la primitive bind(...) est d’associer a une socket une adresse a usage du monde exterieur.

quelle est la difference avec l'adresse que l'on precise avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 SOCKADDR_IN sin;
 sin.sin_addr.s_addr = inet_addr("127.0.0.1");
 sin.sin_port = htons(21);

J'ai realise un programme qui envoi/recoi des donnees sans cette fonction.
Quelle utilitee cette fonction peu elle apportee a un programme.

Merci

[Emmanuel Delahaye]

je n'arrive pas a comprendre l'utilite de la fonction bind().

Le role de la primitive bind(...) est d’associer a une socket une adresse a usage du monde exterieur.

quelle est la difference avec l'adresse que l'on precise avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 SOCKADDR_IN sin;
 sin.sin_addr.s_addr = inet_addr("127.0.0.1");
 sin.sin_port = htons(21);

J'ai realise un programme qui envoi/recoi des donnees sans cette fonction.

Parce que tu utilises un mode non connecté et que tu précises les informations d'adressage à chaque envoi ou reception avec sendto() ou recvfrom().

Quelle utilitee cette fonction peu elle apportee a un programme.

bind() est la fonction qui créée le lien entre la socket et le monde extérieur. Une fois que bind() a été appelée, la socket garde l'info. On peut ensuite utiliser des fonctions plus simples comme send() et recv(). Evidemment, ça ne fonctionne qu'en mode connecté (genre TCP/IP).

[vic]

bind() est la fonction qui créée le lien entre la socket et le monde extérieur.

Non tu confonds avec connect(). La fonction bind() permet de lier une socket à une adresse ou un port donnés.

Exemple 1 : Quand on se connecte à un serveur, en général on ne précise pas le port local qui est choisi automatiquement par la couche réseau de l'OS. Parfois on peut souhaiter fixer le port local, on doit alors bind()er préalablement sur le port voulu.

Exemple 2 : Tu as un PC avec plusieurs IP (par exemple 2 cartes réseau), si tu crées une socket en listen() sans faire de bind() on pourra se connecter dessus en passant aussi bien par l'une ou l'autre carte réseau. Si tu souhaites limiter la connexion à une IP seulement, il faut utiliser la fonction bind(). C'est utile par exemple sur une passerelle pour autoriser les connexions depuis le réseau local mais pas depuis internet.

[chacal]

en mode non connecter (UDP) la fonction bind() peu donc etre utilisee pour cette meme utilisation ?

[vic]

A priori oui.

[SuperCed]

je n'arrive pas a Evidemment, ça ne fonctionne qu'en mode connecté (genre TCP/IP).

TCP est un protocole avec connexion. IP fonctionne en mode déconnecté, udp aussi.

[Aramis]

TCP est un protocole avec connexion. IP fonctionne en mode déconnecté, udp aussi.

N'importe quoi! IP est un protocol de niveau 3 dont le but est d'achemine le paquet avec "Best Effort". L'une des raisons pour les quelles la couche de transport (couche 4), dont TCP et UDP font parti, c'est justement pour corriger le fait que parfois l'arrive des paquets doit etre guarantie.

The internet protocol is specifically limited in scope to provide the
functions necessary to deliver a package of bits (an internet
datagram) from a source to a destination over an interconnected system
of networks. There are no mechanisms to augment end-to-end data
reliability, flow control, sequencing, or other services commonly
found in host-to-host protocols.

C'est pourquoi, il est preferable de ne pas atteindre les meme conclusions pour des protocols qui ont ete fondamentalment penses differements

Ar@mi$

[SuperCed]

Je ne comprends pas ou est la contradiction...
J'aurais du dire IP et udp fonctionnent en mode "sans connexion" peut -être.

TCP est un protocole avec connexion.

IP est un protocol de niveau 3 dont le but est d'achemine le paquet avec "Best Effort". L'une des raisons pour les quelles la couche de transport (couche 4), dont TCP et UDP font parti, c'est justement pour corriger le fait que parfois l'arrive des paquets doit etre guarantie.

Je suis d'accord également. Les modes "avec connexion/sans connexion" sont indépendants de la correction et reprise sur erreur.

Par exemple, la couche lisaison(niveau 2) du protocole Ethernet fait de la correction d'erreur alors que les transferts se font sans connexion.
Et l'exemple contraire serait le réseau téléphonique qui fonctionne avec connexion (commuté) mais sans contrôle d'erreur car il n'est pas très important de garantir l'intégrité de la voix.

Peux-tu m'expliquer la contradiction? Je ne suis pas un spécialiste du réseau, mais je ne demande qu'à apprendre.

[ced2004]

aramis parle du model osi qui est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
couche 7) application
couche 6) presentation
couche 5) session
couche 4) transport
couche 3) reseau
couche 2) liaison de donnée
couche 1) physique

(ce n'est qu'un model)

ou celui qui envoie part de la couche 7 jusqu'a la couche 1 et celui qui reçoit part de la couche 1 et va jusque qu'a la couche 7 sachant que la couche 1 représente les bits (ex 10011101) et la chouche 7 représente les donnés que l'application comprend (TOTO achet 1, qui pourrait dire pour l application toto achet le produit numero 1)...
un peut dur a comprendre...

soit ...

TCP et UDP sont du niveau de la couche 4 et IP est du niveau de la couche 3
TCP est avec correction d'erreur et orienté connection ("assure" que les données sont bien arrivé grace à un ACK)
UDP est un protocole sans correction d'erreur et n'est pas orienté connection ( envoie d'une donnée sans savoir si l'hote distant les a bien recu)
UDP est plus rapide mais moin fiable.

la couche 4 donne un adresse de transport ( numero de port, FTP 21, SNMP 161, pop3 110,...)
couche 3 donne l'adresse réseau (IP) 192.168.0.1,10.59.5.6,...
couche 2 donne l'adresse physique (MAC) 000C:6F5A:7A0C

donc superCed ici on ne peut pas faire la comparaison entre des couches differentes.
TCP et UDP c'est une chose. IP c'est une autre chose.
je sais pas si c'est claire....

et le bind() c'est pour associer une adresse IP a un port (si je me trompe pas) donc sur internet un machine avec l'addresse IP 217.59.53.254 et le port 21 veut dire que la machine avec cette adresse IP a un serveur FTP se qui est unique (si on parle pas de NAT, PAT, ...) et peut avoir un autre serveur comme SSH, SFTP,mail,Web,...

[SuperCed]

Je connais le modèle OSI, et tout ces trucs là.

Je n'ai pas comparé des protocoles de niveaux différents, j'ai simplement dit que IP n'était pas un protocole orienté connexion. Je ne vois pas en quoi cela pose un problème.

Connexion en français s'écrit avec un "x".

Je suis d'accord avec tout ce que tu dis aussi.
Je ne vois pas ou est le problème, et pourquoi on ne peut pas comparer des protocoles de niveaux différents.

[ced2004]

si on oublie tout se qui est protocole et qu'on parle juste des adresses, on ne peut pas comprarer des ports avec des adresses IP.
pour le protocole c'est le meme chose, les protocle de la couche 3 s'occupe du routage des paquets
et les protocole de la couche 4 s'occupe d'ajouter de la correction d'erreur ou pas, sans s'occuper du routage

[SuperCed]

si on oublie tout se qui est protocole et qu'on parle juste des adresses, on ne peut pas comprarer des ports avec des adresses IP.
pour le protocole c'est le meme chose, les protocle de la couche 3 s'occupe du routage des paquets
et les protocole de la couche 4 s'occupe d'ajouter de la correction d'erreur ou pas, sans s'occuper du routage

Oui, mais on peut quand même les comparer, même s'ils n'ont pas la même fonction.

De toutes façons, ce n'était pas l'intérêt principal de mon message. Je soulignais juste le fait que IP n'était pas orienté connexion, c'est tout.
As-tu déjà utilisé des sockets IP directement? Si tu regardes la doc, tu verras qu'il n'y a pas de connect ou de listen. Ca fonctionne comme de l'UDP à ce niveau.
Mais bien sur, quand tu utilises un socket UDP, il y a la couche IP en dessous.

Donc bref, j'ai toujours été d'accord avec tout ce qui a été dit dans ce topic.

[Aramis]

Re,

Oui, mais on peut quand même les comparer, même s'ils n'ont pas la même fonction.

Peux tu comparer un poirreau et une tomate? Non car le premier est un legume et le second est un fruit pourtant les deux sont mangeables : : Avec des arguments pareils on ne s'en sortira jamais.

Cependant, je tiens a souligne que le model OSI a ete specialement cree a cet effet. Chaque couche fournit des services ou bien se charge de certaines choses pour les couches adjacantes. Ces couches sont interchangeables. On pourrai tres bien faire du TCP sur IPX. Par consequent, la modularite ne permet pas les comparaisons.

Certains ouvrages sur les reseaux disent que le model OSI a rendu difficile l'apprentissage des principes de communication entre machine mais a rendu plus facile (et c'etait le but) l'inter-connexion de machines heterogenes. Peu etre cette histoire de comparaison "impossible" tombe dans la categorie de la difficulte d'apprentissage

Ar@mi$

[SuperCed]

Re,

Oui, mais on peut quand même les comparer, même s'ils n'ont pas la même fonction.

Peux tu comparer un poirreau et une tomate? Non car le premier est un legume et le second est un fruit pourtant les deux sont mangeables : : Avec des arguments pareils on ne s'en sortira jamais.

Bien sur qu'on peut comparer un poireau et une tomate!!! on peut comparer leur couleur, leur forme, leur goût, etc. Mais comme tu le dis, avec de telles discutions, on s'en sortira jamais.

De toutes façons, comme je l'ai déjà dit plus haut, ce n'est absolument pas la partie importante de mes posts, et en plus, je n'ai jamais comparé des protocoles de niveaux différents.

Et je suis d'accord aussi avec tout ce que tu as dit.
Bref, je ne vois toujours pas d'où vient le désacord...