Discussion :

[Heroiik]

Bonsoir,

je suis un tutoriel sur les sockets BSD en c (http://lacl.univ-paris12.fr/cegielski/sec/ch6.pdf) section 6.3.10 et je comprend pas quelque chôse, dans le code ont crée un socket client et un serveur, ensuite je m'y connect grâce à mon navigateur et le socket client envoi au serveur la page qu'il veut afficher, donc pour une fois c'est le client qui envoi la page et non le serveur, sauf que pour envoyé le code il faut d'abord lire une ligne. Hélas il n'explique pas pourquoi... si quelqu'un peut me dire pourquoi ont ne peut pas seulement envoyé la page sans avoir à lire ce que le serveur nous à envoyé.

Merci d'avance

[Obsidian]

Bonjour,

Une fois la connexion établie, ce qui transite par le canal mis en place ne concerne plus le système et n'est donc pas relatif aux sockets proprement dits.

En l'occurrence, il s'agit simplement d'une petite simulation d'un serveur web. À cette occasion, le client indique au serveur la page qu'il souhaite consulter et celui-ci la lui renvoie. La lecture de ligne en question sert donc juste à recevoir la requête du client même si elle n'est jamais analysée en elle-même et que c'est toujours la même page qui est renvoyée ensuite.

[Heroiik]

Salut et merci de ta réponse.

La lecture de ligne en question sert donc juste à recevoir la requête du client

Cela veut dire que la requête du client n'est jamais envoyé au serveur ?

Dans ce cas en quoi la récupérer, permet de continuer l’échange d'information ?


Merci.

[Obsidian]

Si tu te « connectes avec ton navigateur », alors le client, c'est ce navigateur.

La totalité du code que tu vois entre les pages 140 à 142 du document que tu nous présentes est celui du serveur, exclusivement. L'ambiguïté vient probablement du fait que ce que tu appelles socket client est ici celui qui correspond à la connexion, en gardant bien à l'esprit qu'une application peut gérer plusieurs connexions simultanément. Les sockets sont initialement une interface unifiée pour faire de la communication inter-processus en environnement BSD, mais ce n'est que par extension qu'ils sont devenus le mécanisme privilégié pour gérer le réseau (en partie pour raisons historiques, d'ailleurs). Donc, à la base, les sockets sont un peu des descripteurs à tout faire.

Quand tu mets en place un « serveur », tu crées une application qui fonctionne à l'arrière-plan, se met à l'écoute des connexions entrantes et sert les informations demandées par les homologues qui se sont connectés. Vis-à-vis de la programmation système et des sockets, cela va se traduire par :

• La création initiale d'un socket (a priori relié à rien) ;
• L'association d'une adresse particulière à ce socket grâce à bind(). Tu peux donc lui attribuer une adresse sur le réseau mais également dans d'autres domaines, comme la famille UNIX (ce qui te permet de te « connecter à un nom de fichier », ce qui est un concept assez subtil) ;
• Le passage en mode écoute de ce socket avec listen(). Ce n'est qu'à ce stade que tu vas pouvoir commencer à recevoir des connexions entrantes ;
• L'acceptation d'une connexion entrante avec accept().

C'est ce dernier point qui est important : lorsque tu appelles accept(), cette fonction te renvoie un autre socket qui, lui, correspond à la connexion établie entre ton serveur et son homologue. Ça lui permet de la traiter individuellement et de la refermer avec close() en fin de dialogue. Le premier socket, lui, continue de vivre sa vie et est toujours à l'écoute. On peut même accepter une nouvelle connexion entrante alors que la première n'est pas encore terminée. accept() renverra encore une fois un nouveau socket propre à cette connexion. Dès lors qu'on ferme le premier socket, c'est tout le serveur qui cesse d'être à l'écoute et les connexions entrantes sont refusées par le système.

En résumé, donc, coté serveur :

• Un socket pour recevoir toutes les connexions entrantes, PLUS…
• Un socket par connexion établie.

[Heroiik]

Ah d'accord, merci d'avoir pris le temps de m'expliquer, je viens de comprendre mais ce document est flou (pour un débutant comme moi )



Bonne journée !

[Obsidian]

Ah d'accord, merci d'avoir pris le temps de m'expliquer, je viens de comprendre mais ce document est flou (pour un débutant comme moi )

À ton service. Pour être honnête, je ne suis pas très fan de ce document non plus. Certes, la personne qui l'a écrit a essayé d'être pédagogue et a une réelle volonté de transmettre son savoir mais certains de ces exemples sont mal choisis. Par exemple, pour illustrer l'OOB, plutôt qu'un client qui passe devant tout le monde à la boulangerie, j'aurais plutôt choisi de parler d'une ambulance qui emprunte la bande d'arrêt d'urgence, ou qui utilise son gyrophare pour demander la priorité quand elle circule en ville. Ces deux derniers cas auraient été en rapport avec les réseaux qui disposent de canaux dédiés (par exemple le canal de service D des connexions ISDN) et les réseaux hors-connexions par paquet, comme Internet, dans lesquels on peut marquer un datagramme pour en signifier la priorité.

Bonne journée !

De même, mais n'oublie pas le bouton « résolu » en bas de page.
Merci.