Bonjour à tous,
j'avais testé de communiquer avec des processus via des tubes nommés et le principe de fonctionnement était tres compréhensible, si je voulais communiquer avec deux processus j'ouvrai un tube nommé sur mon programme serveur, et j'attendais que le client envoie un message sur le tube nommé du serveur. Le message qu'envoyait le client était le tube nommé du client, et je pouvais ainsi communiquer: Je fesais l'appelle systeme read sur le descriptor de fichier du tube nommé du client et un write sur le descripteur de fichier du tube nommé du serveur.
J'ai fait cet exercice car j'imaginais les sockets fonctionnaient comme ca sauf qu'ils échangent des adresses IP à l'initialisation et non des tubes nommés comme je fais, mais en faite pas du tout.
Le probleme c'est qu'en TCP par exemple j'utilise les appelles systeme read et write mais sur le meme descriptor de fichier alors qu'avec les tubes nommés j'avais un descripteur de fichier pour lire et un autre pour écrire.
Comment avec les sockets je peux lire et écrire sur la meme zone mémoire car je pourrais tres bien lire ce que je viens d'écrire.
J'espere que vous avez compris mon probleme.
Merci d'avance pour votre aide
# La socket TCP est un canal bidirectionnel
Posté par goeb . Évalué à 2.
Non. La socket TCP est un canal bidirectionnel comme si tu avais dans un même tuyau 2 tubes (un pour chaque sens).
Si A est connecté à B par une socket TCP, les octets écrits par A seront lus par B et inversement. A ne pourra pas relire ce qu'il aura écrit dans la socket.
Le file descriptor est un identifiant logique qui permet de désigner un bout de la socket.
[^] # Re: La socket TCP est un canal bidirectionnel
Posté par Eh_Dis_Mwan . Évalué à 1.
Pour plus de précision, il me semble même qu'il s'agit de "buffers réseaaux", et en réception et en envoi, nous avons en effet 2 buffers différents:
Sous linux, ils sont configurables en modifiants quelques sysctl:
https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-network-dont-adjust-defaults
https://www.cyberciti.biz/faq/linux-tcp-tuning/
Comme il s'agit de zones mémoires, les augmenter peuvent diminuer sensiblement les performances de la machine
[^] # Re: La socket TCP est un canal bidirectionnel
Posté par viviNeutron . Évalué à 1.
pour vous il y a donc 2 buffers différents lors de la lecture et de l'écriture, ce qui me semble logique. Mais lorqu'on utilise les appels systemes read et write on donne le meme file descriptor en argument, c'est ca qui me gene
[^] # Re: La socket TCP est un canal bidirectionnel
Posté par Eh_Dis_Mwan . Évalué à 1.
c'est pas "selon moi", c'est selon différents kernel (linux, windows aussi, voir applications)
je suis pas developpeur, mais je pense que tu pourra trouver certaines pistes ici:
http://poincare.matf.bg.ac.rs/~ivana/courses/ps/sistemi_knjige/pomocno/apue/APUE/0201433079/ch17lev1sec4.html
[^] # Re: La socket TCP est un canal bidirectionnel
Posté par NeoX . Évalué à 3.
faut pas etre géné
c'est ensuite le kernel qui va aller sur le bon buffer selon que tu demandes read ou write,
c'est magique, et c'est tant mieux, ca te simplifie quand meme vachement la vie ;)
[^] # Re: La socket TCP est un canal bidirectionnel
Posté par viviNeutron . Évalué à 1.
ok c'est plus clair maintenant, merci beaucoup pour vos réponses :)
# IPCs
Posté par David Marec (site web personnel) . Évalué à 2.
En fait, non.
Je n'ai pas compris si le comportement des sockets, soit deux flux différents en lecture et écriture, vous convient ou pas.
Si oui, et que vous souhaitez communiquer entre deux process locaux, utiliser les sockets UNIX, plutôt que TCP ou UDP, voire une socketpair.
Si non, regardez du coté des shared memory (
shm).Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.