Discussion :

[Joyus]

Bonjour,

Je cherche à savoir quelle est la différence entre les tubes nommés (s_ififo) et fichiers socket (s_ifsock) et dans quel cas utiliser doit-on utiliser l'un ou l'autre.

Vous savez vous ?

[Sve@r]

Vous savez vous ?

Ouais, nous on sait !!!

Je cherche à savoir quelle est la différence entre les tubes nommés (s_ififo) et fichiers socket (s_ifsock)

Un fichier de type pipe (fifo) est un fichier de communication synchrone entre deux processus situés sur la même machine. Ses caractéristiques font que la première info entrée sera la première à en sortir. De plus, si les deux processus ne sont pas présent en même temps, le noyau bloquera l'ensemble jusqu'à ce que tout soit prêt. C'est pratique quand on veut protéger une ressource unique (comme une imprimante). Toute impression passe par un tube qui est lu par un processus lpd et qui est envoyé sur l'imprimante. Et un second processus lpr sert à prendre le fichier à imprimer et à l'envoyer sur le tube. Et si deux utilisateurs appellent lpr en même temps, comme le noyau bloque l'accès au tube, les deux impressions ne se mélangeront pas dans l'imprimante.
Exemple simple pour tester ce phénomène
1) on ouvre un terminal dans lequel on tape
mknod toto p
date >toto => là le curseur se bloque => normal, on écrit dnas le tube et personne ne va le lire

2) on ouvre un second terminal dans lequel on tape
cat toto => on récupère la date envoyée par le premier terminal et celui-ci est débloqué


Un fichier socket est un fichier de communication synchrone entre deux processus situés sur la même machine mais les outils permettant de communiquer via ce fichier sont les mêmes que ceux qui permettent de communiquer via la pile TCP/IP. La fonction d'écriture dans un socket sera la même que pour envoyer des infos dans le réseau. Seul la phase d'initialisation (socket ou tcp/ip) sera différente. C'est donc assez pratique quand on veut faire une appli qui doit marcher indifféremment que ce soit entre deux machines ou sur la même. Le corps de l'appli ne change pas, seul l'initialisation de l'appli peut bouger. En revanche, pas de blocage. Si on écrit sur la socket et que personne ne lit le flux, soit l'écriture est refusée, soit elle est perdue (je sais plus trop).

et dans quel cas utiliser doit-on utiliser l'un ou l'autre.

Ca c'est toi qui décide en fonction de tes besoins...

[Joyus]

Ouaow, ca c'est de la réponse, dit !

Par contre, quand tu dis que les 2 communications ne se mélangent pas avec un s_ififo, tu es sûr de ça ? J'ai codé un exemple qui me donne le contraire.

SI j'ouvre mon programme "serveur" qui crée un tube en lecture et 2 clients qui ouvrent un tube en écriture, les 2 clients peuvent écrire en même temps et le serveur affiche bien le texte envoyé par les client. Aucun client n'est bloqué en attendant que l'autre est terminé.

J'ai vu aussi un article sur internet qui préconise d'utiliser une structure d'envoi de données pour faire du multiplexage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
struct {
  int id; // identifiant de l'appelant
  int taille;
  char buffer[1024];
}