log out
< bye

Si au bout d'un certain temps, le contrôleur ne reçoit aucun message d'un programme d’affichage, celui-ci est supprimé de l’aquarium. Pour éviter d’être considéré comme déconnecté par le contrôleur, il est donc nécessaire de le contacter à intervalles réguliers. On utilisera pour cela une commande Ping.

Deux commandes peuvent être utilisées : ls et getFishesContinuously
La commande ls empile toutes les réponses en une seule fois. Ici ils retournent 3 lignes directement. La commande getFishesContinuously permet de retourner les réponses de manière périodique dans la connexion TCP/IP ouverte.

ls
< list [PoissonRouge at 92x40,10x4,5] [PoissonClown at 22x80,12x6,5]
< list [PoissonRouge at 70x40,10x4,5] [PoissonClown at 10x90,12x6,5]
< list [PoissonRouge at 30x30,10x4,5] [PoissonClown at 30x30,12x6,5]

Le contrôleur retourne au programme d’affichage la liste des poissons que doit gérer ce dernier en continu, ici 3 réponses sont générées directement et qui prennent en compte les aspects de mobilité des poissons.
A noter que le contrôleur peut communiquer a priori le chemin complet que doit prendre un poisson en suivant des points bien précis. Dans ce cas, le programme d’affichage doit parser toutes les positions et les exécuter une à la suite des autres.

-> OK: Connecté au controleur, X poissons trouvés
Fish [NomFish] at [PosFish],[SizeFish]
...

log out
< bye

Si au bout d'un certain temps, le contrôleur ne reçoit aucun message d'un programme d’affichage, celui-ci est supprimé de l’aquarium. Pour éviter d’être considéré comme déconnecté par le contrôleur, il est donc nécessaire de le contacter à intervalles réguliers.

Faudra utiliser la classe prompt je pense pour print dans le terminal, si on veut être cohérent

Nom :
Dimension :
Position :
Mobilité :

Si au bout d'un certain temps, le contrôleur ne reçoit aucun message d'un programme d’affichage, celui-ci est supprimé de l’aquarium. Pour éviter d’être considéré comme déconnecté par le contrôleur, il est donc nécessaire de le contacter à intervalles réguliers. On utilisera pour cela une commande Ping :

ping 12345
< pong 12345

Première demande

getFishes
< list [PoissonRouge at 90x4,10x4,5] [PoissonClown at 20x80,12x6,5]
Le contrôleur retourne au programme d’affichage la liste des poissons que doit gérer ce dernier.
Ici le programme d’affichage courant doit gérer deux poissons : PoissonRouge et PoissonClown. Le PoissonRouge doit nager depuis sa position courante vers la position 90x4 (en pourcentage de la taille de l’écran). Cette mobilité (ou cette nage) doit durer 5s. A noter que les paramètres de mobilité entre la position actuelle du poisson et sa nouvelle position sont à la discrétion de chaque programme d’affichage. Le contrôleur ne fait que communiquer la position finale (i.e. 90x4)du poisson et la durée d’exécution de la mobilité (5s).
Attention: les coordonnées peuvent être négatives dans le cas d’un poisson qui entre ou sort de la vue de l’afficheur.
Pour afficher instantanément un poisson à une position par exemple lorsqu’il rentre dans une vue, la valeur de temps est mise à 0 . list [PoissonRouge at 90x4,10x4,0] [PoissonClown at 20x80,12x6,5] ⇒ ici PoissonRouge s’affiche dès la réception de cette commande à la position indiquée.

add view N5 400x400+400+200
-> view added

$ delFish PoissonNain
-> OK
$ delFish PoissonNain3
-> NOK : Poisson inexistant

hello in as ID
< greeting ID
À l'initialisation, le programme d’affichage communique au contrôleur son identifiant qui doit correspondre à un vrai nœud dans la topologie de l’aquarium, c’est à dire un afficheur (exemple N1 , N2, N3 ou N4). L’identifiant est fixé au démarrage du programme d’affichage ou lu depuis le fichier de configuration.

Si l'identifiant demandé est libre (c’est à dire pas pris par un autre clientà, le contrôleur autorise son utilisation.

hello in as N3
< greeting N3

Si le programme d’affichage n'a pas spécifié d'identifiant, le contrôleur lui attribue un identifiant libre (le reste de la commande n’est pas nécessaire dans ce cas).

hello
< greeting N2
Si l'identifiant demandé n'existe pas dans la topologie, ou lorsqu’il est déjà attribué à un autre affichage, le contrôleur renvoie si possible un autre identifiant libre sinon une erreur

hello in as N404
< greeting N4

hello in as N505
< no greeting

addFish PoissonRouge at 90x40,10x4, RandomWayPoint
< OK
Si le nom du poisson existe déjà dans l’aquarium:
addFish PoissonRouge at 90x40,10x4, RandomWayPoint
< NOK

• InitNetwork qui initialise la connection du client avec la socket et instancie les différentes commandes dans le dictionnaire

• closeNetwork qui ferme la connection du client avec la socket

Si au bout d'un certain temps, le contrôleur ne reçoit aucun message d'un programme d’affichage, celui-ci est supprimé de l’aquarium. Pour éviter d’être considéré comme déconnecté par le contrôleur, il est donc nécessaire de le contacter à intervalles réguliers. On utilisera pour cela une commande Ping :

ping 12345
< pong 12345

load aquarium
-> aquarium loaded (4 display view)

$ addFish PoissonNain at 61x52, 4x3, RandomWayPoint
-> OK
$ addFish PoissonNain2 at 45x4, 10x10, PathWay
-> NOK : modèle de mobilité non supporté

delFish PoissonRouge
< OK
Si le nom du poisson n’existe pas dans l’aquarium:

delFish PoissonRouge
< NOK

Les algorithmes de déplacement (RandomPathWay par exemple) sont à destination du contrôleur: il détermine la façon dont le serveur va déplacer le poisson : une nouvelle position toutes les 5 secondes par exemple. On pourra imaginer un algorithme HorinzontalPathWay qui fait qu’un poisson se déplace toujours horizontalement et toujours dans le même sens (il devrait ainsi tourner entre les clients).
Concernant  getFishesContinuously, plusieurs solutions sont possibles côté contrôleur:

getFishesContinuously
< list [PoissonRouge at 92x40,10x4,5] [PoissonClown at 22x80,12x6,5]
// 3 seconds après par exemple le contrôleur transmet une nouvelle liste.
< list [PoissonRouge at 70x40,10x4,5] [PoissonClown at 10x90,12x6,5]
// 3 seconds après par exemple le contrôleur transmet une nouvelle liste.
< list [PoissonRouge at 30x30,10x4,5] [PoissonClown at 30x30,12x6,5]
Dans cet exemple, le contrôleur envoie un “liste” chaque fois qu’un poisson arrive à destination (ici au bout de 5 secondes). On pourrait également implémenter un contrôleur qui envoie une “list” toutes les 3 secondes:
getFishesContinuously
< list [PoissonRouge at 92x40,10x4,5] [PoissonClown at 22x80,12x6,3]
< list [PoissonRouge at 70x40,10x4,4] [PoissonClown at 10x90,12x6,2]
< list [PoissonRouge at 30x30,10x4,3] [PoissonClown at 30x30,12x6,1]
Du point de vue du client, cela ne devrait pas changer l’implémentation. Dans le deuxième cas, on confirme les destinations régulièrement, ce que l’on ne fait pas dans le premier cas.

-> NOK : modèle de mobilité non supporté

save aquarium
-> Aquarium saved !( 5 display view)

Les algorithmes de déplacement (RandomPathWay par exemple) sont à destination du contrôleur: il détermine la façon dont le serveur va déplacer le poisson : une nouvelle position toutes les 5 secondes par exemple. On pourra imaginer un algorithme HorinzontalPathWay qui fait qu’un poisson se déplace toujours horizontalement et toujours dans le même sens (il devrait ainsi tourner entre les clients).
Concernant  getFishesContinuously, plusieurs solutions sont possibles côté contrôleur:

getFishesContinuously
< list [PoissonRouge at 92x40,10x4,5] [PoissonClown at 22x80,12x6,5]
// 3 seconds après par exemple le contrôleur transmet une nouvelle liste.
< list [PoissonRouge at 70x40,10x4,5] [PoissonClown at 10x90,12x6,5]
// 3 seconds après par exemple le contrôleur transmet une nouvelle liste.
< list [PoissonRouge at 30x30,10x4,5] [PoissonClown at 30x30,12x6,5]
Dans cet exemple, le contrôleur envoie un “liste” chaque fois qu’un poisson arrive à destination (ici au bout de 5 secondes). On pourrait également implémenter un contrôleur qui envoie une “list” toutes les 3 secondes:
getFishesContinuously
< list [PoissonRouge at 92x40,10x4,5] [PoissonClown at 22x80,12x6,3]
< list [PoissonRouge at 70x40,10x4,4] [PoissonClown at 10x90,12x6,2]
< list [PoissonRouge at 30x30,10x4,3] [PoissonClown at 30x30,12x6,1]
Du point de vue du client, cela ne devrait pas changer l’implémentation. Dans le deuxième cas, on confirme les destinations régulièrement, ce que l’on ne fait pas dans le premier cas.

Ajouter puis tester une par une les commandes dans le dictionnaire networkCommand et promptCommand

Nom:
Fonction destination (position -> position)

Adresse IP du nœud contrôleur

controller-address = a.b.c.d

Identifiant du programme d'affichage

id = N1

Numéro de port TCP d'écoute du nœud contrôleur

controller-port = 12345

Valeur par défaut pour la transmission du ping.

display-timeout-value = 30

Répertoire relatif ou absolu où se trouve les visuels pour les poissons.

resources = ./fishes

startFish: [NameFish]
-> OK

getFishes
< list [PoissonRouge at 90x4,10x4,5] [PoissonClown at 20x80,12x6,5]
Le contrôleur retourne au programme d’affichage la liste des poissons que doit gérer ce dernier.
Ici le programme d’affichage courant doit gérer deux poissons : PoissonRouge et PoissonClown. Le PoissonRouge doit nager depuis sa position courante vers la position 90x4 (en pourcentage de la taille de l’écran). Cette mobilité (ou cette nage) doit durer 5s. A noter que les paramètres de mobilité entre la position actuelle du poisson et sa nouvelle position sont à la discrétion de chaque programme d’affichage. Le contrôleur ne fait que communiquer la position finale (i.e. 90x4)du poisson et la durée d’exécution de la mobilité (5s).
Attention: les coordonnées peuvent être négatives dans le cas d’un poisson qui entre ou sort de la vue de l’afficheur.
Pour afficher instantanément un poisson à une position par exemple lorsqu’il rentre dans une vue, la valeur de temps est mise à 0 . list [PoissonRouge at 90x4,10x4,0] [PoissonClown at 20x80,12x6,5] ⇒ ici PoissonRouge s’affiche dès la réception de cette commande à la position indiquée.

Numéro de port TCP d'écoute

controller-port = 12345

Temps entre 2 requêtes au-delà duquel un programme d’affichage est retiré du réseau.

display-timeout-value = 45

Intervalle en secondes pour l'échange périodique de poisson. cf. commande GetFishesContinuously

fish-update-interval = 1

Deux commandes peuvent être utilisées : ls et getFishesContinuously
La commande ls empile toutes les réponses en une seule fois. Ici ils retournent 3 lignes directement. La commande getFishesContinuously permet de retourner les réponses de manière périodique dans la connexion TCP/IP ouverte.

ls
< list [PoissonRouge at 92x40,10x4,5] [PoissonClown at 22x80,12x6,5]
< list [PoissonRouge at 70x40,10x4,5] [PoissonClown at 10x90,12x6,5]
< list [PoissonRouge at 30x30,10x4,5] [PoissonClown at 30x30,12x6,5]

Le contrôleur retourne au programme d’affichage la liste des poissons que doit gérer ce dernier en continu, ici 3 réponses sont générées directement et qui prennent en compte les aspects de mobilité des poissons.
A noter que le contrôleur peut communiquer a priori le chemin complet que doit prendre un poisson en suivant des points bien précis. Dans ce cas, le programme d’affichage doit parser toutes les positions et les exécuter une à la suite des autres.

appeler toutes les méthodes de ConfigParser pour initialiser la vue et les différents paramètres

modifier initNetwork pour utiliser les attributs plutôt que des valeurs choisi lors de l'exécution du client

delFish PoissonRouge
< OK
Si le nom du poisson n’existe pas dans l’aquarium:

delFish PoissonRouge
< NOK

Peut être judicieux de crée une classe gestionnaire de configuration qui va permettre la création de fichier de configurations et la lecture de configuration
A réfléchir, il faut surtout pouvoir répondre à cette question : dans le fichier de configuration pour la vue, il met l'id de la vue, ça veut dire qu'il faut en créer, à la main, un pour chaque vue ?

L'idée est de pouvoir récupérer les différentes variables du fichier de configuration pour la vue :

# Adresse IP du nœud contrôleur
controller-address = a.b.c.d

# Identifiant du programme d'affichage
id = N1

# Numéro de port TCP d'écoute du nœud contrôleur
controller-port = 12345

# Valeur par défaut pour la transmission du ping.
display-timeout-value = 30

# Répertoire relatif ou absolu où se trouve les visuels pour les poissons.
resources = ./fishes

Commande :
del view N5
Retour :
view N5 deleted

Réaliser une proposition de l’organisation des classes pour le contrôleur.

On doit pouvoir avoir une interface de type prompt qui se chargera essentiellement du parsing :

• lire le terminal
• comprendre l'instruction demandée et exécuter l'instruction
• envoyer des informations à l'utilisateur dans le terminal après avoir exécutée l'instruction

L'exécution d'une instruction peut se faire son la forme d'une "commande". Cela permettra notamment de coder des instructions. Une commande possède :

• un nom
• des paramètres
• un résultat de retour
• une fonction

La commande peut réaliser des instructions du protocole de communication interne. Il faut donc aussi réfléchir à la forme que ces instructions peuvent prendre.

L'idée est que l'on puisse coder des commandes et des instructions du protocole de communication interne sans savoir comment la communication avec le terminal fonctionne.
De plus, on doit pouvoir coder des instruction du protocole de communication interne sans connaître les commandes.

Réaliser une proposition de l’organisation des interfaces .h pour la vue.

On doit pouvoir avoir une interface de type prompt qui se chargera essentiellement du parsing :

• lire le terminal
• comprendre l'instruction demandée et exécuter l'instruction
• envoyer des informations à l'utilisateur dans le terminal après avoir exécutée l'instruction

L'exécution d'une instruction peut se faire son la forme d'une "commande". Cela permettra notamment de coder des instructions. Une commande possède :

• un nom
• des paramètres
• un résultat de retour
• une fonction

La commande peut réaliser des instructions du protocole de communication interne. Il faut donc aussi réfléchir à la forme que ces instructions peuvent prendre.

L'idée est que l'on puisse coder des commandes et des instructions du protocole de communication interne sans savoir comment la communication avec le terminal fonctionne.
De plus, on doit pouvoir coder des instruction du protocole de communication interne sans connaître les commandes.

Commande :
show aquarium

Retour :
1000x1000
N1 0x0+500+500
N2 500x0+500+500
N3 0x500+500+500
N4 500x500+500+500

hello in as ID
< greeting ID
À l'initialisation, le programme d’affichage communique au contrôleur son identifiant qui doit correspondre à un vrai nœud dans la topologie de l’aquarium, c’est à dire un afficheur (exemple N1 , N2, N3 ou N4). L’identifiant est fixé au démarrage du programme d’affichage ou lu depuis le fichier de configuration.

Si l'identifiant demandé est libre (c’est à dire pas pris par un autre clientà, le contrôleur autorise son utilisation.

hello in as N3
< greeting N3

Si le programme d’affichage n'a pas spécifié d'identifiant, le contrôleur lui attribue un identifiant libre (le reste de la commande n’est pas nécessaire dans ce cas).

hello
< greeting N2
Si l'identifiant demandé n'existe pas dans la topologie, ou lorsqu’il est déjà attribué à un autre affichage, le contrôleur renvoie si possible un autre identifiant libre sinon une erreur

hello in as N404
< greeting N4

hello in as N505
< no greeting