Socket de type Unix/Stream

bonjour tout le monde

voilà

je voudrais écrire un programme (serveur) en c qui ouvre une Socket de type Unix/Stream pour écoute, le chemin vers la Socket doit être choisis de telle façon a éviter le besoin d'un compte possédant des droits de super-utilisateur.

pour tester le serveur, un programme (client) qui contactera le programme serveur a travers la Socket Unix ouverte par serveur et lui enverra un message "hello there !". le programme serveur lorsqu'il reçoit le message affiche la date et l'heure et répond ""hello overthere!".

l’environnement de travail: linux, gcc, man

si quelqu'un peut m'aider je lui serait éternellement reconnaissant

merci d’avance

Bienvenue et bonne année 2015.

Nous ne ferons pas ton travail à ta place mais nous pouvons te guider pour que tu y parviennes. Où en es-tu actuellement au niveau programmation système en général et des sockets en particulier ? As-tu déjà commencé à écrire un programme ? Si oui, poste-le ici (avec les balises CODE) et nous serons en mesure de le commenter.

Bon courage.

merci pour votre réponse rapide

j'ai honte de le dire mais je suis au niveau zero (j'ai l'habitude de travailler avec c# et vb.net)

si vous ne voulez pas m'aider (et c'est tout a fait normal) dites moi au moins comment éviter le compte super utilisateur
et comment écrire dans la Socket

encore merci

(joyeux noël et bonne année)

Un peu d'aide parce que la programmation réseau est assez pénible au début: on a une petite dizaine de fonctions et il faut connaître les 3-5 combinaisons qui fonctionnent.

Donc voici le guide le plus complet :mrgreen:

Sinon une petite indication (d'après ton message initial): pas de mot de passe, alors c'est une connexion datagram (UDP) qu'il faut utiliser.

Citation:

Envoyé par K4YT0 KiD

merci pour votre réponse rapide

j'ai honte de le dire mais je suis au niveau zero (j'ai l'habitude de travailler avec c# et vb.net)

Ce n'est pas une honte. :-) Nous avions juste besoin de le savoir pour t'orienter correctement.

Citation:

si vous ne voulez pas m'aider (et c'est tout a fait normal) dites moi au moins comment éviter le compte super utilisateur
et comment écrire dans la Socket

Pour éviter le compte super-utilisateur, il faut simplement choisir un emplacement dans lequel l'utilisateur courant a le droit d'écrire, tout simplement. La première chose qui viendrait à l'esprit est le home (qui n'est pas fait pour ça) mais, en réalité, l'endroit le plus approprié pour faire cela est le répertoire « /tmp », tout simplement. Ce répertoire est destiné aux fichiers temporaires qui peuvent être effacés lors d'un redémarrage. Ça correspond tout-à-fait à ce qu'il nous faut. Par contre, c'est un dépôt accessible à tous les utilisateurs et il faudra éviter les collisions en choisissant un nom de fichier approprié. Il faudra également passer le nom de fichier à l'application cliente.

Pour les sockets en particulier, fais une recherche sur ce forum car ils ont été évoqués de nombreuses fois, mais formellement, il s'agit d'une très vieille interface définie historiquement par les UNIX de la famille BSD, à l'origine pour être un système unifié pour faire de la communication inter-processus (en réponse aux IPC de SysV), interface « orientée fichier » comme tout ce qui l'est en principe sous UNIX, et qui permet donc de les exploiter avec les appels de traitement de fichiers ordinaires comme open, close, write, read, auxquels on a ajouté notamment send et recv.

Les sockets étendaient d'une part le concept de tube anonyme et de tube nommé qui existaient déjà sous UNIX (attention : ceux de Windows ne fonctionnent pas de la même façon), notamment en les rendant bidirectionnels, mais le concept vraiment intéressant a été l'introduction de famille d'adresses à laquelle on pouvait éventuellement les associer, de façon à pouvoir les ouvrir et donc les contacter, exactement sur le principe du tube nommé. C'est ce concept de famille d'adresse qui les a rendus naturellement aptes à gérer le réseau (qui ne disposait pas encore d'interface standard et unifiée) et c'est pour cela qu'ils se sont imposés, y compris sous Windows qui n'a en fait proprement pris en charge les technologies Internet qu'à partir de Windows 95.

Ça veut dire que l'adresse d'un socket dépend du domaine dans lequel tu veux la créer. Si c'est une adresse IP, on considère que tu es sur Internet de manière générale (même si en fait, il s'agit d'un réseau local, en 192.168.x.x, par exemple) et tu choisiras AF_INET. Comme ici, on veut créer un socket dans le domaine UNIX original, on précisera AF_UNIX (« AF » signifiant « Adress Family »). Et dans le domaine UNIX, l'espace d'adressage est le système de fichier, tout simplement. Associer un socket jusque là anonyme à une adresse UNIX avec bind() va donc créer une entrée dans le système de fichiers, visible avec ls ou avec un explorateur de fichier, mais reconnu comme tel au même titre qu'un répertoire (un dossier) ou un lien symbolique. Par la suite, les applications vont se « connecter à ce nom de fichier » comme on se connecterait à une adresse réseau et donc entrer en relation avec l'application qui tourne derrière, comme lorsque l'on ouvre un tube nommé, même si c'est une notion un peu surprenante de prime abord.

Donc, en gros :

Ton application serveur crée un socket avec l'appel socket(). Elle te renvoie un descripteur de fichier qui lui correspond et qui est compatible avec ceux qui te sont renvoyés par open() ;
Tu définis une adresse dans le domaine de ton choix. Pour ce faire, tu déclares une variable du type « struct sockaddr_un » et tu la remplis dûment. Ensuite, tu passes le tout (descripteur du socket et adresse de la structure) à bind(). Ceci crée l'entrée dans le système de fichier ;
Tu passes le socket en mode écoute pour en faire un serveur et donner la possibilité aux applications de se connecter en passant son descripteur à listen(). Avant cet appel, les connexions entrantes sont rejetées. Après, elles sont mises en attente jusqu'à ce que tu les traites ;
Tu fais une boucle sans fin impliquant accept(), en passant là encore le descripteur du socket. À ce stade, l'application est mise en attente jusqu'à ce qu'une connexion devienne disponible. L'appel te renvoie alors le descripteur d'un autre socket qui, lui, te permet de dialoguer avec l'homologue qui vient de se connecter. Il ne faudra pas oublier de le refermer avec close(), et éventuellement shutdown(). Le socket initial, lui, continue d'exister pour recevoir d'autres connexions ;
Quand tu as fini, tu sors de la boucle, et tu refermes la connexion en terminant le socket initial de la même façon qu'au point précédent.

Deux points subtils cependant : la gestion des adresses proprement dites (et des types qui leur sont associés) va te paraître un peu confuse : c'est parce qu'il s'agit en fait d'héritage, un concept formalisé par la suite en programmation orientée objet, mais utilisé à une époque où celle-ci était encore balbutiante et où le C lui-même ne pouvait pas le prendre en charge. Ensuite, le nom de fichier créé est une authentique entrée dans le catalogue du système de fichier et ne disparaît pas automatiquement lorsque l'application se termine. Il faudra donc penser à faire le ménage (en l'effaçant normalement avec rm, ou unlink() depuis le C).

Cerise sur le gâteau : le processus sera exactement le même si tu veux faire une vraie application réseau (un serveur web, par exemple). Seule la famille de l'adresse changera. Il faudra aussi ensuite penser à gérer les spécificités du domaine exploité (par exemple, la durée de vie des sockets et le délai de grâce avant ré-attribution d'une adresse) mais le principe est là.