Admin CliCours
Extrait du cours implémentation de TCP UDP les sockets
1 – GENERALITES
Les caractéristiques des sockets sont décrites par des constantes déclarées que l’on trouve dans la bibliothèque : sys/socket.h.
Le domaine d’une socket précise si elle est :
– locale au système AF_UNIX on a alors
struct sockaddr_un{
shortsun_family;
char sun_path[108];
}
– accessible au domaine INTERNET AF_INET, on a alors
struct sockaddr_in
short sin_family;
u_short sin_port;
struct in_addr sin_addr;
char sin_zero[8];
}
D’autres domaines peuvent exister dont nous ne parlerons pas : X25, XEROX, DEC, …
Le type d’une socket est le protocole sous-jacent transporté :
– SOCK_STREAM est le protocole TCP,
– SOCK_DGRAM est le protocole UDP,
– SOCK_RAW est l’accès direct au protocole IP qui est le protocole de la couche 3 sur INTERNET, il est réservé aux super-utilisateurs,
– SOCK_SEQPACKET correspond au protocole XEROX.
La création d’une socket se fait par appel à la fonction int socket (domaine,type,protocole)
2 – PROTOCOLE UDP : SOCKET SOCK_DGRAM
Ce protocole ne permet pas à l’expéditeur de savoir si son message est arrivé mais il préserve les séparations entre messages. Le protocole NFS s’appuie sur UDP. Le processus qui désire communiquer par ce moyen doit
– disposer d’une socket sur le système local
– d’une adresse de son interlocuteur.
Les primitives sont les suivantes :
int sendto( sock, /* socket d’émission */
msg, /* adresse du message */
l g , /* longueur du message*/
option, /* =0 pour SOCK_DGRAM */
p_dest, /* pointeur adresse socket de réception */
lgdest /* longueur de l’adresse de réception */
)
int recvfrom(sock, /* socket d’émission */
msg, /* adresse de récupération du message */
lg, /* taille de l’espace de récupération */
option, /* =0 ou MSG_PEEK */
p_exp, /* pointeur adresse socket expéditrice */
lgdest /* longueur de la zone allouée à p_exp */
)
3 – PROTOCOLE TCP : SOCKET SOCK_STREAM
Le protocole TCP suppose un flot continu contrôlé de données, il y a établissement d’un circuit virtuel entre les deux éléments communiquant. Il y a donc un initiateur de la communication, le client, qui demande à l’autre, le serveur, s’il accepte la communication. Il est clair qu’il y a donc dissymétrie complète entre les deux codes.Le serveur dispose d’une socket d’écoute et lorsqu’une demande parvient au système, il est réveillé. Une nouvelle socket dite de service est créé et le travail est délégué par le serveur à un nouveau processus créé par fork. C’est lui qui assurera le service alors que le serveur est remis en veille d’écoute sur la socket d’écoute.
L’algorithme du serveur est grossièrement :
– création et attachement de la socket d’écoute,
– ouverture du service par écoute
– boucle infinie consistant à attendre une demande, créer un sous processus de traitement.
Les primitives permettant sa réalisation sont :
– une primitive de création de file d’attente de connexions entrantes int listen (sock,nb)
– une primitive d’acceptation de connexion qui renvoit un descripteur de socket int accept(sock,p_adr,p_lgadr)
……..
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Cours implémentation de TCP/UDP les sockets (87 KO) (Cours PDF)
