Bonjour à tous,
voilà, je me suis lancé il y a un an dans le développement d'un messenger en Java avec une approche architecturale différente de celle des messengers actuels. J'ai bossé dessus 3 semaines...
Je suis seul. J'ai réouvert ce projet au début de ce mois avec la ferme intention de proposer une version stable en release candidate pour Novembre 2007. Un an d'attente, de démangeaisons et de frustrations car je devais boucler d'autres choses avant...Je suis réellement passionné par ce que je fais, mais la passion ne doit pas conduire à faire n'importe quoi, ni dans un mur.
Le projet supporterait nativement:
- le tunneling pour console xbox, et par généralisation le tunneling de tout traffic réseau intérressant, plus tard la recherche automatique de joueurs.
- des salons de discussion, et par généralisation des groupes de partage,
- le transfert de fichiers et la recherche de fichiers,
- des conversations vidéos et vocales par groupe ou privées,
- lecteur média (mp3, vidéos, etc...),
- la création d'interfaces (programmation) publiques utilisables pour l'ajout et la suppression de modules, proposables au grand publique.
Puis plus tard l'ouverture aux autres systèmes avec l'intégration de protocoles tels que xmpp (Jabert, etc)
On se dirigerait doucement vers une plate-forme...
J'ai tout une foule de questions, j'ai toujours des réponses, mais les réponses d'aujourd'hui ne seront pas forcément celles de demain. C'est délicat, étant seul il me faut faire des choix qui réduisent les temps de développement, immédiatement mais pour l'évolution également. Celà implique de faire les choses à grande échelle, sans se gourrer.
C'est dans cette optique que j'aurais vraiment besoin d'un BRAINSTORMING sur de nombreux points (critique, démontage, discussion, avantage, inconvénient, quelles librairies utiliser, etc)
Ma première question est sur la gestion des groupes coté serveur.
J'ai des groupes, des sessions, des dépendances entre session.
Une session est vivante, ou morte.
Joindre un groupe revient à référencer la session du participant dans l'objet groupe.
J'ai choisi une programmation événementielle, cad que l'ajout ou la suppression d'une session à un groupe déclenche des évenements.
Les clients correspondant aux sessions affectées reçoivent alors des données.
Lorsqu'une déconnection du client arrive (voulue ou non), la session devient morte.
Un groupe peut comprendre des sessions mortes (cable reseau débranché, coupure internet). L'évenement onDisconnect de la session est alors déclenché.
Comment nettoyer ces sessions mortes?
Solution 1:
Méthode asynchrone: un thread ou un pool de thread chargés de "maintenir" et de "controler" les groupes. Pendant un laps de temps, des sessions mortes peuvent appartenir à un groupe. Le problème dans cette approche, c'est que les autres participants ne seront informés de ce changement d'état que lorsque le thread s'occupera du salon et en informera la participants.
C'est un problème d'avoir une personne visuellement connectée et présente dans un salon alors qu'elle ne l'est plus depuis 2 minutes. Et augmenter les fréquences des controles c'est utiliser plus de ressources, peut etre pour rien...et mettre à genoux le serveur.
Solution 2:
Méthode synchrone: garder en session une référence vers tous les objets qui se serviraient de la session. Retirer de tous ces objets la session morte au déclenchement de l'évenement onDisconnect(). Déclencher des méthodes dans ces objets etc... Group.onQuit() Group.onJoin() etc...
L'avantage c'est que le client est tout de suite informé que la personne s'est déconnectée. Le désavantage c'est le gavage phénoménale des sessions des utilisateurs et par conséquent l'occupation mémoire d'une session grandissante. Un serveur de 64Gb devrait pouvoir accueilir au moins 30000 personnes (davantage possible à cause de l'architecture choisie apr rapport à d'autres messengers)
Je sais pas trop quoi faire, c'est surtout comment garder un lien avec les objets référencés sans monter une usine a gaz qui m'embete.
Une autre question, c'est le formalisme des échanges entre client et serveur, ou de client à client directement.
J'utilise CLI, une API de ligne de commande:
par exemple pour joindre un salon un client envoi
join -group Rencontres -login netdoor
autres alternatives à la ligne de commande?
le serveur, lui répond avec des objets Java sérialisés et envoyés au client.
Ces objets sont des executables, cad qu'une fois reçus par le client il comprennent une méthode executeOnClient() qui encapsule le code à exécuter à la réception de l'objet sur le client.
cout des objets via réseau? autre formalisme ou possibilités?
Voilà, merci d'avance à tous pour vos critiques, idées, etc...
Partager