Discussion :

[pirbd]

Bonjour,

Nous developpons une famille d'applications deployée sur plusieurs postes d'un meme reseau.
Une de ces applications ne doit pas être lancée plus d'une fois simultanément.

L'algo actuel garantissant cette unicité est :
Qd l'application demarre, elle regarde si elle trouve en base de données (unique pour tous les postes) des traces de vie récentes de l'application.
* si oui, elle refuse de se lancer (message utilisateur)
* si non, se lance normallement et ecrit des traces de vie regulierement en BD

Cet algo n'est pas robuste puisque si 2 instances de l'application demarrent exactement en meme temps, elle vont pouvoir toutes les 2 s'executer normalement.

J'avais pensé passer par une application "moniteur" s'executant sur la partie serveur a qui on pourrait demander l'autorisation de se lancer. Mais nos serveurs etant dupliqués (un serveur de secours), le developpement de ce "moniteur" n'est pas triviale...

Avez-vous d'autres idées pour garantir l'instance unique de mon programme ?
Par exemple, est-il possible de reserver une ressource reseau commune a plusieurs poste ? (en s'inspirant de l'ouverture d'une socket en local qui peut permettre de garantir une seule instance d'une application sur un meme poste)

Si vous connaissez un meilleur endroit pour poster cette question, n'hesitez pas non plus

Merci d'avance

[Mac LAK]

Avez-vous d'autres idées pour garantir l'instance unique de mon programme ?

Plusieurs pistes :

• Envoi d'une trame UDP broadcast (sorte de "ping") sur le réseau pour vérifier la présence (ou non) d'une autre instance.
  Peut être fait à plusieurs reprises : démarrage initial de l'application, et juste avant de démarrer les opérations. Une attente plus ou moins aléatoire (genre 100 à 1000 ms) peut permettre d'éviter les problèmes de démarrage simultané, bien que normalement les algos d'émission CSMA/CD du réseau devraient déjà permettre ça.
  
  La réponse à cette trame en diffusion peut contenir, notamment, l'adresse IP et/ou le nom d'ouverture de session (nom d'utilisateur, souvent) et/ou le nom de machine de façon à savoir QUI a ouvert l'application : cela évitera le problème inévitable de la personne qui ouvre l'application, verrouille son poste et part prendre un café en bloquant tout le monde...
• Verrouillage d'un fichier sur un répertoire réseau, et/ou création en verrouillant l'écriture d'un fichier avec un nom connu à l'avance (les autres le voient en lecture seule, donc).
  Ce fichier peut contenir, en cas de création, les mêmes informations que la réponse au "ping" de façon à pouvoir "lire" dedans ces informations de localisation de l'instance active.
  L'atomicité de l'opération de création/lock est garantie par le système d'exploitation hôte du partage, donc pas de souci particulier.

Personnellement, je ferais les deux en même temps histoire d'être tranquille :

1. Un "ping" réseau (UDP broadcast) pour savoir si une instance est ouverte.
2. Si oui, message à l'utilisateur + sortie.
3. Si non, tentative de création d'un fichier réseau en accès exclusif.
4. Si la création échoue, émission d'un "ping" réseau pour savoir qui a ouvert l'application et/ou lecture du fichier de verrouillage pour avoir les informations sur la personne ayant ouvert l'application. Bien sûr, avertissement à l'utilisateur et sortie ensuite.
5. Si la création fonctionne, autoriser les opérations nominales.
6. A la fermeture de l'application, destruction du fichier de lock.

Pour les trames UDP, il faut et il suffit de créer un serveur dans ton application, ainsi qu'un client, et ceci le plus tôt possible. Tant qu'à faire, colle ça dans un thread histoire d'être certain que ça ne va pas être bloqué par une quelconque opération dans le thread principal.

Prévoir le cas d'un crash de l'application, et donc la possibilité de supprimer le fichier de lock (ou de supprimer le verrouillage sur un fichier existant) de façon à permettre une nouvelle ouverture de l'application.