LIENS ET TELECHARGEMENTS
Voici les documents au format pdf que j'ai utilisé pour faire ce site:
www.i3s.unice.fr/~menez/Teaching/Maitrise_Info/Networking/socket.pdf
www.essi.fr/~riveill/cours/reseau1/94-poly-sockets.pdf
Un résumé du contenu de ce site au format PowerPoint:
Présentation "Les sockets sous UNIX"
Maintenant les différents exemples de programmes en C.
Domaine Internet
Mode connecté (T.C.P.)
Serveur et client "Inverse" : Le programme
client se connecte au programme serveur. Il lui envoie les mots entrés sur la
ligne de commande, le serveur lui renvoie les mots avec les lettres dans l'ordre
inverse.
La syntaxe du client est:
$> ClInvTCP NumPortLocal NomMachineServeur
NumPortServeur Mot1 Mot2...
Celle du serveur est :
$> SeInvTCP NumPort
Serveur concurrent
"Inverse" : Fonctionne avec des clients "ClInvTCP"
normaux, cette fois le serveur traite plusieurs clients simultanément en
délégant chaque connexion à un processus fils.
La syntaxe du serveur est :
$> SeInvTCPConc NumPort
Mode déconnecté (U.D.P.)
Serveur et client
"Double" : Le client envoie dans un datagramme un nombre de type
long au serveur. Celui-ci affiche les coordonnées du client, calcule le double
de ce nombre et l'envoie au client. Cet exemple permet de voir les étapes de
conversion pour envoyer un nombre sur le réseau.
La syntaxe du client est :
$> ClDoubleUDP NomMachineServeur NumPortServeur
Celle du serveur :
$> SeDoubleUDP NumPort
Client "Broadcast"
: Ce client fonctionne avec des serveurs "SeDoubleUDP" normaux.
Ceci est un exemple de client qui envoie un datagramme en broadcast à tous les
programmes serveur qui écoutent sur le même port. Dans ce cas, il faut faire
attention car le client ne sait pas combien de serveurs vont lui répondre. Il
faut donc faire un select sur la socket et traiter dans une boucle tous les
datagrammes reçus. On considère qu'après un certain temps d'attente sans rien
à lire sur la socket (timeout de select) tous les serveurs ont répondu.
Il faut faire attention aussi au fait que chaque serveur doit être sur une
machine différente car par défaut un port n'est utilisé qu'une fois. Ceci
peut ce changer (grâce à setsockopt) mais dans ce cas le broadcast ne marche
pas car c'est le premier processus qui lit la socket qui aura le message. On
peut dire à chaque processus de lire sans extraire le contenu de la socket avec
l'option MSG_PEEK sur recvfrom, mais dans ce cas le message reste tout le temps dans la
socket, dont le buffer de réception saturera... Il faudrait désigner un
ordre de lecture des serveurs en disant que le dernier extrait le message au
lieu de le laisser, un peu compliqué quand même pour ce que ça fait.
La syntaxe du client est :
$> ClDoubleUDPBroad NumPortServeurs
AdresseBroadcast
Serveur à entrées multiplexées "SeDouUDPMult"
: Ce serveur fonctionne avec les clients "ClDoubleUDP". Ce dernier est
un exemple de l'utilité du polymorphisme et de la compatibilité de l'API
socket avec les I/O d'Unix. En effet, le serveur se sert de select pour
répondre aux clients distant le double du nombre reçu et de faire la même
chose sur l'entrée standard.
La syntaxe du serveur est :
$> SeDoubleUDPMult NumPort
Serveur et client
"Inverse" : Cela fait la même chose que le mode connecté mais
cette fois chaque mot est envoyé dans un datagramme différent. J'ai utilisé
la technique que j'explique dans la page "III/
Domaine Internet". Je créé donc un buffer dans lequel je met la
taille du message suivit du mot.
La syntaxe du client est:
$> ClInvUDP NumPortLocal NomMachineServeur NumPortServeur Mot1 Mot2...\
Celle du serveur est :
$> SeInvUDP NumPort
Domaine Unix
Mode connecté
Serveur et client "Double" : Pareil que dans le
domaine Internet, mais avec des sockets systèmes cette fois
La syntaxe du client est:
$> ClDouUNIXCon NomSocketServeur
Celle du serveur est :
$> SeDouUNIXCon NomSocket
Mode déconnecté
Serveur et client "Double" : Pareil que ci dessus, en mode déconnecté.
La syntaxe du client est:
$> ClDouUNIXDec NomSocket NomSocketServeur
Celle du serveur est :
$> SeDouUNIXDec NomSocket