clavardator/NOTES.md

Notes

Connexion initiale

• envoie en broadcast (UPD) de son login
• chaque utilisateur le compare à son propre login et se reserve le droit de refuser
• le client est donc en attente de réponses
• Comment savoir que tout le monde est ok ? Demander au premier qui répond sa liste et l'intégrer
• si tout le monde inscrit sur cette liste dit ok -> c'est bon
• raffiner la liste des actifs au fur et à mesure

Communication

• Discussion TCP quand on veut envoyer des messages (reset le socket avec un timeout pour économiser ?)
• Détection d'utilisateurs devenus inactifs sur timeout
• Associer un ID à un utilisateur (on peut faire l'hypothèse qu'on est sur un réseau pro et donc l'ip change pas)

Gestion historique

Décentralisée ou centralisée sur serveur, au choix

• Décentralisé:
• Chaque noeud à une bdd locale -> Serveur SQL qu'on veut (SQLite plus simple)

Rapport

expliquer l'archi et les choix expliquer schéma bdd relationnelle manuel utilisation appli plus import -> procédure déploiement