La programmation par Socket

La communication entres applications sur Internet présente l'énorme avantage d'être standardisée !
Que vous travailliez sous Windows, Linux, Mac, OS/400, etc...vous retrouverez toujours une pile IP qui comprend les mêmes fonctions de base permettant de faire communiquer des ordinateurs très différents sur un même protocole et de la même façon.

Dans tous les cas, vous aurez un serveur et un client.

Le serveur est l'ordinateur qui propose un service. Il est en fait simplement à l'écoute des clients potentiels.
Le client est l'ordinateur qui va solliciter le service...d'un serveur bien évidemment.

On pourrait penser que dans le P2P (peer to peer), il n'y a que des clients. En réalité, un des deux ordinateurs est serveur et l'autre client du premier. Il existe cependant un cas particulier ou les deux noeuds sont clients, mais ils doivent alors impérativement passer par un serveur intermédiaire dont ils sont tous les deux clients qui se charge de faire suivre les messages de l'un vers l'autre; dans eMule on parle alors de LowID.

Le principe des adresses IP

La communication par internet se compare assez facilement aux communications téléphoniques. Quand un ordinateur veux dialoguer avec un autre, il doit connaitre son numéro de téléphone adresse IP. Tout comme notre annuaire téléphonique, il existe un annuaire des adresses IP par le biais des serveurs de noms (DNS Domain Name Server).

Le cas des adresses IP publiques

Dans la configuration IP de votre ordinateur on trouve obligatoirement l'adresse IP d'au moins un serveur de nom. Sans cela il serait impossible d'obtenir les adresses des autres serveurs. Le serveur DNS que vous utilisez est généralement celui de votre fournisseur d'accès à Internet, et ce paramétrage est bien souvent obtenu automatiquement par DHCP (un autre protocole Internet).

Prenons un exemple, si je tape http://www.google.fr dans un navigateur, celui ci va commencer par chercher l'adresse IP du serveur portant le nom www.google.fr. En utilisant la commande PING dans une fenêtre de commande, vous pouvez trouver une des adresses de ce serveur :

C:\>ping www.google.Fr

Envoi d'une requête 'ping' sur www.l.google.com [209.85.135.104] avec 32 octets
de données :

Réponse de 209.85.135.104 : octets=32 temps=50 ms TTL=243
Réponse de 209.85.135.104 : octets=32 temps=51 ms TTL=243
Réponse de 209.85.135.104 : octets=32 temps=50 ms TTL=243

Statistiques Ping pour 209.85.135.104:
    Paquets : envoyés = 3, reçus = 3, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    minimum = 50ms, maximum = 51ms, moyenne = 50ms

Le site google étant un serveur Web, le navigateur va alors établir une connexion sur l'adresse IP obtenue (209.85.135.104) sur le port 80. Le numéro de port correspond en effet au service Web offert par l'ordinateur distant; ce même ordinateur pourrait également offrir d'autres services avec la même adresse IP mais sur d'autres numéros de port.

Notez qu'il est cependant tout à fait possible d'accéder à un serveur ne possédant pas de nom pour peu qu'on connaisse son adresse IP.

Le cas des adresses IP privées

Google, qui possède une adresse IP publique, est joignable depuis n'importe quel ordinateur connecté à Internet. Mais il existe des plages d'adresses IP privées qui sont réservées pour les réseaux internes. C'est le cas de votre ordinateur s'il est branché derrière une "box" avec d'autres PC; chez Free par exemple, la Freebox utilise par défaut un réseau 192.168.0.x qu'il est impossible de joindre depuis une autre connexion Internet.

Une comparaison simple est celle du standard téléphonique. Je peux joindre les personnes qui ont une ligne directe, mais il est impossible d'appeler les autres, il faut impérativement passer par le standard et demander un numéro de poste. Et justement, les box possèdent une fonction de routage très similaire. Il est possible de rediriger les connexions entrantes de l'adresse IP publique de la box (qui en possède elle forcément une) vers l'un des PC interne. On se basera non pas sur un numéro de poste, mais tout simplement sur le numéro de port. Ainsi, toutes les requêtes du port 80 peuvent-elles être redirigées vers un PC interne qui offre un service Web.

En conséquence, si votre PC est dans un réseau privé et qu'il doit être joignable depuis Internet, il faut configurer votre router pour qu'il redirige les port nécessaire vers votre adresse privée. L'inverse n'est pas nécessaire car la fonction du routeur est justement de faire suivre vos requêtes vers le net avec son adresse IP publique :)

UPnP est un protocol permettant à un client de configurer automatiquement le routeur; c'est ce qu'utilise Skype par exemple (voir Portmap).

Deux modes de base, UDP et TCP


Les échanges sur le net se font de différentes façon. Au niveau des applications, il existe deux modes couramment utilisés, UDP et TCP. La différence entre les deux est simple, dans le cas d'UDP on envoie un message à destination d'une adresse IP, de la même façon que vous poster un courrier papier sans mettre votre adresse au dos de l'enveloppe. Dans le cas de TCP une connexion est établie entre les deux ordinateurs de tel sorte que si le message ne devait pas parvenir au destinataire, un code d'erreur nous en informerait; on peut comparer ce mode de communication à l'envoie avec accusé de réception.

UDP est parfois utilisé dans les jeux réseaux en temps réel afin de bombarder de message UDP un serveur qui pourra en perdre une partie (lag) sans que cela ne perturbe réellement le jeu car les informations sont très souvent mise à jour. Ce mode de communication permet le mode broadcast (message pour tout le monde) qui peut être utilisé sur un réseau local (n'imaginez pas pouvoir broadcaster tout Internet :D) et le mode multicast qui s'adresse à tous les ordinateurs s'étant fait connaitre dans un sous réseau particulier. Le multicast ne fonctionne généralement pas non plus sur le net.

TCP est plus simple dans un certain sens, avant de pouvoir envoyer un message, il faudra établir une connexion avec le destinataire, s'il n'est pas disponible ou s'il refuse la connexion, le message ne pourra pas être envoyé.

TCP offre donc un support supplémentaire sur UDP car on sera informé de la coupure de connexion par exemple, alors que pour dialoguer en UDP il faudra travailler avec des délais de réponse dépassés (timeout) car c'est l'absence de réponse qui indiquera que le correspondant n'est plus disponible.

Au delà de la connexion, le protocole


Maintenant que nous avons une vague idée sur la communication TCP/IP, il reste à utiliser ou définir un protocole. Pour garder mon analogie au téléphone, ce n'est pas tout de composer un numéro de téléphone et que le correspondant décroche, encore faut-il que mon correspondant et moi parlions la même langue :)

C'est à ce niveau qu'on trouvera les différents protocoles standardisés que sont HTTP, FTP, SMTP, LDAP, etc...

Les sockets IP

Nous venons de voir rapidement comment fonctionnent les connexions IP. Sur l'ensemble des systèmes d'exploitation qui supportent internet, on trouve le même jeu de fonctions permettant de manipuler les sockets. On trouve notamment :
  1. bind qui permet de définir un service IP
  2. connect qui permet de se connecter à un serveur
  3. accept qui permet au serveur d'accepter la connexion cliente
  4. send pour envoyer des données dans un sens ou dans l'autre
  5. recv pour en réceptionner les données envoyées

Sous Delphi, on trouvera ces fonctions dans l'API Winsock de Windows.

Mon unité LDAP est un exemple d'utilisation des sockets pour se connecter sur un service d'annuaire. Et le projet SIPInside reprend les différents protocoles nécessaires à la mise en place d'une communication SIP.
Date de dernière modification : 09/08/2015