Discussion :

[ZeGuizmo]

Salut à tous,

Je me pose une question très simple, mais que je à laquelle je n'ai pas de réponse.

J'écris une application de type client-serveur. Mon serveur est en multithread et délègue les tâches au pool de thread quand des messages se présentent pour se replacer immédiatement en écoute.

De ce coté, c'est testé, pas de soucis particuliers.

Mon problème est du coté client. J'ai plusieurs processus sur un seul client qui veulent tous parler au serveur, et je ne sais pas comment gérer l'accès au socket. Si deux veulent prendre la parole en même temps, ben un des deux se mange une erreur. Il pourrait faire un truc du genre reessayer toutes les secondes, mais je n'aime pas trop cette solution. Si on a vraiment pas de bol, il est possible qu'un processus ne parle jamais.

A la limite, un peu plus propre, un envoi de signal du processus qui parle quand il a fini de parler pour dire aux processus en attente que la voie est libre, mais ça me semble toujours bancal comme solution.

Un truc propre serait de faire un processus qui monopolise le socket en écriture et qui fonctionne à l'inverse du client serveur, il lit une mémoire partagée ou un truc du genre et les processus viendraient y coller leurs messages, le processus qui gere le socket les envoie, recupere la réponse et la met aussi dans la mémoire partagée, qui sera lue par le processus qui envoyait le message.

Je ne trouve pas tellement d'exemple de bonne manière sur le net. On trouve des millions de serveurs mais souvent les applis clientes sont assez délaissées et je n'ai rien trouvé sur l'accès concurrent en écriture au socket.

Auriez-vous une idée ? Une des solution que j'avance tient-elle la route ?

Merci et bonne soirée

Cyril

[Médinoc]

Je crois que ça n'est tout simplement pas recommandé: Normalement, chaque processus client utilise son propre socket pour parler au serveur.

Par contre, avec plusieurs threads au sein d'un même processus (et j'insiste sur la terminologie), je conseillerais l'emploi d'un objet de synchronisation comme un mutex.

[ZeGuizmo]

Aie, ok je vois, pour le mutli-threading c'est ce que je fais, de la mutex pour verrouiller les accès aux ressources.

Je vais embrayer sur une question un peu plus orientée réseau alors, ma machine sera dans un réseau privé et le service informatique qui gère ce réseau veut bien me router un port de leur IP publique vers ma machine pour qu'elle puisse dialoguer, mais pas plus d'un.

Comment utiliser une socket pour chaque processus avec un seul port de routé dans les deux sens.

Sachant que, bien évidemment, le serveur est externe au réseau privé en question donc la seule porte d'entrée est l'IP publique.

Merci

Cyril

[3DArchi]

Aie, ok je vois, pour le mutli-threading c'est ce que je fais, de la mutex pour verrouiller les accès aux ressources.

Je vais embrayer sur une question un peu plus orientée réseau alors, ma machine sera dans un réseau privé et le service informatique qui gère ce réseau veut bien me router un port de leur IP publique vers ma machine pour qu'elle puisse dialoguer, mais pas plus d'un.

Comment utiliser une socket pour chaque processus avec un seul port de routé dans les deux sens.

Sachant que, bien évidemment, le serveur est externe au réseau privé en question donc la seule porte d'entrée est l'IP publique.

Merci

Cyril

Salut,
Un proxy : une com du proxy vers l'extérieur et n comme entre le proxy et les clients internes.

[ZeGuizmo]

Huh

Je ne comprends pas du tout la réponse de 3DArchi, par contre, je n'ai pas du tout la main sur le réseau (mais alors pas du tout) je peux juste insérer une prise RJ45 dans un trou et demander au SI de me router les ports vers la machine, c'est tout. Donc je pense que ce qui est à base de proxy, je peux m'assoir dessus.

Je viens de remarquer un truc qui remet complètement en question ma compréhension des sockets (je vais relire de la doc ce soir...). J'ai fait un test d'écriture de plusieurs process en même temps sur le même port et avec des sleeps bien placés je n'ai pas pu constater de 'error port connection', tout marchait très bien.

Je vais aller relire mes classiques parce que je passe à coté d'un truc là.

Bonne soirée,

Cyril

[3DArchi]

L'idée est d'avoir un processus proxy sur ta machine client :
Tous les processus de ta machine client font leur envoi vers ce processus proxy sur des ports différents.
Le proxy est le seul à envoyer vers l'extérieur. Il joue le rôle de multiplexer en quelque sorte.

Sinon tu peux jouer sur le fait que chaque client à un port distinct et donc une socket différente pour communiquer avec le serveur.