Bonjour a tous
 
Je suis relativement nouvelle en programmation, et je me pose des questions sur la gestion de la memoire lors de l'execution d'un programme.
J'ai fait un client irc en C, qui prend en parametre le serveur irc, le nick, le chanel...
J'aimerais avoir plusieurs client en meme tps, vers des serveurs differents.  
Je peux executer plusieurs fois mon programme en changeant les parametres ou je dois creer une application "mere" qui cree des threads?
 
Merci d'avance pour vos reponses!

ca depend de ce que tu veux en faire : est ce que chaque programme est completement independant, ou est ce que tu veux les faire communiquer ?  
dans le premier cas,  l'independance, dans  l'autre pas

je ne veux pas les faire communiquer. je veux juste etre sure qu'il vont pas "s'ecrire" les uns sur les autres (par exemple les variables locales vont bien etre differentes?)

personne n'a d'idee?

 
A priori, tu peux lancer ton programme plusieurs fois sans que ça pose problème (chaque programme possède sa propre zone en mémoire et donc pas de problème avec les variables locales).
 
Il faut tout de même faire attention à ce qu'ils ne partagent pas de ressources physique.
Exemple, si 2 programmes écrivent dans le même fichier, ça risque de poser problème.

Merci beaucoup!

Mmm c'est etrange les connexions se font bien mais les message n'arrivent pas dans les bonnes socket, tout se melange...
Tu es sur que si je lance deux fois le meme programme il n'y a pas qu'une seule zone memoire commune pour les variables locales?

Houla, c'est une question qui semble simple à la base mais qui est complexe à l'arrivé.
 
Voilà les principaux conflits pouvant survenir quand on exécute en même temps deux fois le même programme :
- tentative d'utilisation du même port réseau
- tentative d'utilisation d'un même fichier
- tentative d'utilisation d'une même ressource matérielle sans passer par les couches d'abstraction de l'os ou en passant par des couches d'abstractions qui n'ont pas prévus de mécanismes d'accès concurrentiel
- utilisation d'une DLL qui travaille sur les même espaces mémoires quelque soit les programmes qui l'appellent. C'est super chiant quand on essaye de trouver d'où viennent les bugs. (peut être l'origine de ton problème)
- dialogue avec la même instance d'un programme tier. Ca n'est pas gênant si le programme tier est prévus prévus pour ça (bases de données par exemple) mais c'est super chiant quand ça n'est pas le cas ("Ms word" par exemple)

Les sockets, c'est justement une ressource partagée, tout comme un fichier sur le disque.
Il ne faut pas que tes programmes utilisent les mêmes port.
 
Si tu dois avoir un port fixe côté client, alors il te faut effectivement une application mère, qui va lancer les différents clients sous forme de Threads ou Processus. Et c'est elle, et elle seule, qui va s'occuper de la partie socket, et faire l'aiguillage entre les différents threads.

Ce n'est pas le couple IP/port qui identifie le socket? Si mes programmes se connectent a des serveurs/port differents, les clients devraient utiliser dynamiquement des ports different cote client?

Ben ça c'est toi qui choisi logiquement ton port d'écoute.
D'après ta description du problème, tous tes clients écoutent en même temps sur le même port, et l'adresse distante ne donnera pas d'info à l'OS pour savoir à qui envoyer l'info : c'est le premier process qui se réveille qui vient lire le buffer réseau, sans chercher à comprendre d'où ça vient logiquement.
 
Mais bon, je voudrais pas trop m'avancer, j'ai pas fait de réseau depuis une éternité... Et je passais par WINSOCK.OCX (contrôle pour VB) qui de toute façon lève une erreur si on tente d'écouter sur un port déjà utilisé par une autre application.
 
Dans tous les cas, ton problème doit venir de là, car tu peux lancer autant de fois la même application, tu ne dois pas avoir de problème de gestion mémoire. En Assembleur, à la limite, tu peux faire l'erreur de forcer la lecture dans une zone mémoire précise, mais ça implique que tu travailles en mode non protégé, et je ne sais même pas si les versions actuelles de Windows le permettent. (le mode non protégé implique que ce n'est pas l'OS qui gère la mémoire du programme, mais le programme lui-même... étant donné que c'était la source de... 99% des écrans bleus de Windows, Microsoft a mis un point d'honneur à faire cesser ce genre de pratiques. notamment si la plupart des programmes MS-DOS ne fonctionnent pas sous Windows XP, c'est souvent à cause de ça)