Discussion :

[Captain'Flam]

Bonjour,

je me tords les neurones sur un script qui doit communiquer avec d'autres instances de lui-même mais qui en ignore l'existence et le nombre.

Je m'explique :

Mon script est lancé depuis différents process du système (je n'ai aucun contrôle là dessus, mais en gros, ils sont tous lancés en même temps (dans la même demie seconde)).
Chaque instance reçoit un paramètre (sur sa ligne de commande).
Je voudrais :
1 - trouver un critère qui me permette de distinguer une des instances pour en faire le maître (les autres devenant les esclaves)
2 - que chaque esclave envoie son paramètre au maître.

J'ai déjà créé une solution qui marchotte...
Chaque instance va essayer d'ouvrir un fichier en écriture.
Quand un script échoue à ouvrir le fichier, il fait un sleep et réessaye plus tard.
Quand un script arrive à ouvrir le fichier, il regarde sa taille : si elle est nulle, c'est qu'il est le premier => il est le maître.
Si la taille n'est pas nulle, c'est un esclave : il écrit son paramètre à la fin du fichier, le referme et se termine.
Pendant ce temps, le maître, scrute la taille du fichier.
Quand elle reste stable pendant (disons) 300ms, il considère que tous les esclaves ont fini.
Enfin, il ouvre à nouveau le fichier pour en extraire tous les paramètres.

J'ai essayé d'autres variantes en utilisant les mmap mais dans tous les cas, ma solution n'est pas satisfaisante.
Dès que trop d'instances sont en concurrence ou que le CPU ou le disque dur sont un peu débordés, ça échoue :
--> le maître "rate" certains esclaves et leur paramètre est perdu
--> il a plusieurs instances qui se croient maître
En gros, à partir d'une vingtaine d'instance, ça commence à débloquer.
On est loin des 100 ou 200 que j'aimerais pouvoir lancer.

Si je viens vous embêter avec ça, c'est parce que je suis sûr de ne pas être le premier à avoir ce genre de besoin.
Il existe sûrement des solutions propres et de bonnes pratiques en la matière.
Mais peut-on le faire en python et de manière portable (Linux/Windows) ?

Merci d'avance.

[PauseKawa]

Bonjour,

Je te propose dans un premier temps une solution simple sur la base de xmlrpclib/SimpleXMLRPCServer(xmlrpc.server attention au passage Python 2 / 3) (ou socket mais c'est légèrement plus compliqué).
Chaque client ayant un thread client et tente de lancer un thread serveur sur une plage de port prédéfinie (localhost).
Si le port est occupé le client tente de se 'présenter'. C'est bon: Le process sur le port en question est le maitre. C'est pas bon on continu.

@+

[ZZelle]

Utiliser un fichier pour synchroniser les différentes instances peut poser quelques problèmes :
- comment assurer que 2 instances n'essaient pas en même temps d'écrire dans le même fichier ? la librairie python-lockfile fournit la base pour résoudre ce genre de problème.
- comment nettoyer le fichier à l'arrêt des instances ? En cas de plantage ? Est-ce un problème dans ton cas ?

J'aurais tendance à faire communiquer les différences instances via xmpp ou AMQP ... petite contrainte, ça oblige à faire tourner un serveur xmpp ou AMQP mais ça permet :
- de faire tourner tes instances sur une ou plusieurs machines
- c'est scalable jusqu'à au moins 100/200 d'instances
- la seule information à fournir aux instances est l'adresse du serveur.

Sinon tu peux peut-être utiliser une base sqlite ?

[pacificator]

Bonjour,

tu peux aussi jeter un oeil sur zeromq.

Bon python

[Captain'Flam]

comment assurer que 2 instances n'essaient pas en même temps d'écrire dans le même fichier ?

Je fais confiance à l'OS. En principe 2 process ne peuvent ouvrir le même fichier en écriture en même temps. C'est même sur cette hypothèse que je me base. D'ailleurs, de tous les problèmes que je rencontre, aucun ne vient d'une faille à ce niveau.

comment nettoyer le fichier à l'arrêt des instances ? En cas de plantage ?

C'est le process qui est devenu maître qui s'en occupe. Grâce aux exceptions, c'est plantage-proof (enfin, je crois).

Je te propose dans un premier temps une solution simple sur la base de xmlrpclib/SimpleXMLRPCServer

Je suis à fond !

[Captain'Flam]

Ayé !
Finalement, je suis parti sur un bon vieux serveur TCP et j'ai obtenu un truc qui marche pas mal (il arrive à tenir une centaine d'instance. après je commence à avoir plusieurs maîtres)
Voici à quoi ça ressemble :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
def try_master ( port,param ):
    import SocketServer
 
    class TCPHandler ( SocketServer.BaseRequestHandler ):
        def handle(self):
            server.res.append( self.request.recv( 2000 ).strip())
    try:
        def timed_out () : server.is_alive = False
        server = SocketServer.TCPServer(('localhost',port),TCPHandler )
        server.res            = [param]
        server.timeout        = 0.5
        server.is_alive       = True
        server.handle_timeout = timed_out
        while server.is_alive :
            server.handle_request()
        return server.res
    except:
        return None
 
def try_slave ( port,param ):
    import socket
    try:
        sock = socket.socket( socket.AF_INET,socket.SOCK_STREAM )
        sock.connect(('localhost',port))
        sock.sendall( param )
    finally:
        sock.close()        
 
def merge_params ( param ):
    return try_master( 56789,param ) or try_slave( 56789,param )
 
files = merge_params( sys.argv[1] )
if files :
    print files

On essaye d'abord de créer le serveur :
si on n'y arrive pas : on devient esclave, on envoie son paramètre et on sort.
si on y arrive : on est le maître en écoute des paramètres des esclaves.
Si le maître reste 0.5s sans rien recevoir, on considère que tous les esclaves ont fini => on revoie la liste de tous les paramètres reçus.
Le seul paramètre à régler c'est le 0.5s de timeout.
Avec 1s ça résiste à plus d'instances, mais si il y en a peu, on attend pour rien.
Le seul hic : il faut esperer qu'il n'y a personne sur le port 56789
En tout cas, c'est beaucoup plus élégant et concis que ma solution à base de fichier partagé...

Merci les gars
Néanmoins, si vous voyez des trucs à améliorer, n'hésitez pas...

[Captain'Flam]

Petit oubli : merci pacificator mais j'aime mieux une solution à base de lib standard.