Discussion :

[netdoor.fr]

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...

[*alexandre*]

c'est quoi une session ?

pour le cas trivial vu que t'as codé ca de facon evenementiel tu peux déjà cloturé une session avec un onClose

sinon, il faudrait déjà savoir comment tu as implementé le mécanisme de communication avec server centralisé ou server décentralisé

j'avais codé un IM sans server centralisé mais pour un réseau local (tous les clients pouvaient devenir server etc) donc un loopback était possible (la seule solution pour savoir si une session est valide ou pas il faut intérogé le client)

maintenant faut savoir si c'est du p2p ou pas ... dans le cas simple avec server centralisé tu as une collection de session qui contient une référence sur un client tu peux donc vérifié la validité d'une session pour un temps donné

sinon pour le reste, j'avais personellement définit un protocole de communication type XML et développer un mécanisme d'abstraction de commandes (ce qui permet justement une ouverture sur d'autres clients)

[netdoor.fr]

Une session est un objet implémenté par moi-même qui contient les données de l'utilisateur pour le système. Oui, en effet la méthode onClose est un moyen de terminer une session. Mais le Garbage Collector ne l'éliminera que si la session n'a aucune dépendance applicative avec d'autres sessions et que si l'objet n'est plus référencé.

En réalité, le client se connecte grâce à TCP sur le serveur, le client s'authentifie via cette connexion, de cette authentification résulte, soit la fermeture immédiate de la connexion en cas d'échec, soit la création d'une session coté serveur et le maintient de la connection TCP avec le client.
Lorsque cette connection est brisée, pour une raison ou une autre, la session devient morte et l'évenement onDisconnect est déclenché. Dans mon cas, le serveur sait immédiatement si la session est valide ou non, inutile d'interroger le client. Lorsque le client a sa connexion brisée, un événement est déclenché et toutes les méthodes adéquates sont exécutées coté client.
Le client passe alors en état "déconnecté".

J'ai en effet une collection de sessions vivantes ou mortes, coté serveur.

La question de la décentralisation est une bonne question.

Le serveur n'est pas un routeur de traffic mais uniquement un service d'authentification et de mise en relation des clients. Chaque client possède un serveur embarqué qu'il déclare au serveur de mise en relation. Le serveur de mise en relation vérifie l'existance de ce serveur embarqué (joignabilité), si le serveur est joignable, un HIGH ID est généré, sinon un LOW ID.

Mais...la aussi, je peu m'assurer de la joignabilité d'un serveur embarqué, mais si un cable est débranché ou autre, j'aurais alors en session, coté serveur, la déclaration d'un serveur embarqué qui n'est plus joignable, et ca m'ennui...

[*alexandre*]

problématique intéressante : Un serveur crash qui prend le relais et gère les clients déjà connectés, comment dispatché les informations et à quelles moment le faire (pour prendre le relais, il faut être tenu informer)

question : un client se connecte à un serveur, le serveur doit il informer des clients qui pourraient prendre potentiellement le relais et lui transmettre les informations concernant ses clients

comment dispatché les informations à qui et à quel moment

[netdoor.fr]

je ne prévois pas de serveur de crash.
En fait, tous les services lancés sur le serveur sont auto-controlés par un gestionnaire, lorsque l'un des services tombe, il est redémarré...c'est tout.

Les serveurs embarqués dans chaque client permettent uniquement de communiquer directement avec un autre client sans passer par le serveur de mise en relation.
Par exemple pour du transfert de fichier le client joint un autre client directement, si ce client dispose d'un HIGH ID et donc d'un serveur embarqué,
Le transfert du fichier démarre alors du client A vers le client B sans générer du traffic au niveau du serveur de mise en relation (pas de routage du traffic par le serveur de mise en relation)

Mais je vois ton idée, forte intérressante, pour gérer cet aspect là, j'envisage plus une toile de serveur de mise en relation, je ne veux pas, conceptuellement, embarquer dans chaque client, un serveur complet de mise en relation car celui va être indégnablement gourmand en ressource et aura besoin d'une machine adéquate et dédiée.

[*alexandre*]

tu peux même abstraire la notion en communication, les communications sont établies directement entre deux clients (transfert de fichier n'est qu'un "type" de communication

pour un groupe, c'est celui qui créer le groupe qui gère les communications et forward les messages