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

[netdoor.fr]

abstract, oui bien sur, je discute la philosophie avant l'implémentation, même si elle est entamée.

Euh...Mettre en charge du groupe le client qui créé le groupe, concept interressant, je vais reflechir si je peu le faire rapidement, si c le cas ca me semble être un bon point pour délester le serveur de mise en relation.

Si t'as d'autres idées ou experiences :p je suis preneur!

[*alexandre*]

faudrait que je revois mon travail d'analyse ca fait trois ans que j'ai pas réflechi à la problématique

[netdoor.fr]

moi ca me semble intérressant cette histoire de gérer un groupe coté client.

Mais certains client sont en LOW ID, cad sans serveur embarqué, ils ne géreront jamais de groupe, d'ou la nécessité de gérer ces groupes coté serveur de mise en relation. Je pense que dans un premier temps, la gestion des groupes coté serveur est une bonne solution.

Je pense aussi que dans un second temps, si tout les participants sont interconnectés via leur serveur embarqué, le owner du groupe pourrait en effet trés bien gérer le groupe et l'émission de données d'information pour ce groupe.

Ce qui est pas mal dans ce cas, c'est la possibilité de "publier/dépublier" par le owner et auprés du serveur de mise en relation, un groupe (la gestion du groupe étant distribuée entre le owner et les participants).

[*alexandre*]

ca peut effectivement être une solution assez peu couteuse du point de vue du client

[netdoor.fr]

Par contre, je sais pas, t'aurais un avis sur la serialisation des objets Java?
et l'utilisation des commandes texte plutot qu'autre chose?
Et référencer dans la session tous les objets ayant référencé la session? et comment implémenter ca de manière générale et proprement.

[*alexandre*]

dans quel contexte tu veux sérialisé des objets java, si tu veux être ouvert à d'autres clients tu peux oublier la sérialisation et rmi

si je dis pas de bétise y a un pattern qui te permetterait de regler ca proprement
je le cherche

non je dis des bétises, tu rends tes sessions persistantes !!! par contre est-ce qu'un simple objet serializable serait suffisant ou l'utilisation d'EJB pourrait t'aider faut voir

y a plein de possiblités, tu peux imaginé également de balader comme tu le suggerais tes objets sur le résaux avec la serialization faire executé des commandes en les balladants également sur le réseaux

etc etc

[netdoor.fr]

rmi c'est clair, j'ai testé, j'ai oublié, surtout avec leur idée de serveur de nom rmi, difficilement transposable à Internet pour partager des objets ou méthodes entre clients et serveur. Conceptuellement, j'oublie.

Le contexte des objets Java sérialisés c'est:
des objets dérivés d'une classe nommée Executable ayant une méthode executeOnClient() et un client qui exécute l'objet à sa réception. Ce qu'il y a de bien dans cette approche c'est que je n'ai pas de traitement spécifique coté client à la réception d'un objet exécutable. J'appel juste la méthode executeOnClient des qu'il s'agit d'un executable. Même chose pour le serveur. C'est vraiment le truc le plus "simple" que j'ai trouvé pour l'instant, mais en effet, pour l'externalisation, c'est mort, car tout est dans un formalisme propriétaire du coup.

C'est pas si mal, ca va éviter que des gens puissent comprendre le fonctionnement du système ou faire des choses illégales avec (trou de sécurité) mais, occupation réseau de ces objets? cout? bon rapport utilité/occupation réseau par rapport à xml par exemple?

Là ou ca se gatte c'est de faire reposer des services de plus haut niveau sur ce principe, je pense au transfert de fichier car pour moi celui-ci devrait pouvoir fonctionner à terme avec des P2P.

[*alexandre*]

http://blogs.msdn.com/dotnetinterop/...10/279743.aspx

résumé

The interesting question from yesterday was, how does the performance of interop using Java serialization compare to the performance of interop using XML serialization? The answer I found: binary serialization is "a little bit" faster.

edit marrant que le premier lien que je choppe avec serialization vs XML soit sur un site de crosoft ...

[*alexandre*]

Là ou ca se gatte c'est de faire reposer des services de plus haut niveau sur ce principe, je pense au transfert de fichier car pour moi celui-ci devrait pouvoir fonctionner à terme avec des P2P.

du temps que tu peux lire écrire dans un flux ... pour du p2p je vois mal envoyé par serialization surtout si tu dois hashé le fichier et envoyé partiellement le contenu

[netdoor.fr]

ouaip, j'ai lu, je pense rester en binaire du coup. :0) lol

Particulièrement parce que j'encapsule le traffic capté depuis la xbox dans un objet java que je sérialise et envoi à l'autre client puis désérialise sur l'autre client et réemet ce meme paquet sur le réseau local.

Et cette opération doît être la plus rapide possible. Donc pour celà, c'est clair, la serialisation binaire est la meilleure solution connue.

Pour le P2P, oui, je pense que je dois me plier à une API existante en fait et fonctionner avec cette API, j'en ai vu quelques unes, aucune idée de quelle est la meilleure...

[*alexandre*]

pas de réponse la dessus, je connais pas d'api sur le sujet

[netdoor.fr]

Ok ok! :0) Quelqu'un aurait il une solution propre pour conserver en session une référence vers tous les objets utilisant cette session? Puis pouvoir agir sur ces objets? Merki

[*alexandre*]

et pourquoi pas un EJB session statefull

[netdoor.fr]

C'est quoi? Je suis en train de regarder mais ca me fait peur quand je vois qu'il faut un serveur d'EJB avec...:-s, c'est une machine de guerre qui va consommer directement énormément de mémoire vive et en plus l'appel d'un EJB depuis un client se fait en RMI puisqu'il s'agit d'un objet distribué.

J'ai déjà fait ce choix en écartant Tomcat d'emblée.

Franchement, je ne suis pas un pro d'EJB, et actuellement l'architecture doit etre "scalable", cad qu'il me faut conserver une relation entre ressource et nombre d'utilisateur connectés. Autrement dit, un serveur sans charge doit couter peu et consommer peu de ressources. Ca me semble un point clef.

S'il s'agit de lancer un serveur qui mange tout de suite 2G de ram alors qu'il n'y a personne de connecté, au niveau des couts, c'est le mur!

Par ailleurs, je suis assez pour le développement qui répond à des besoins.
C'est à dire, commencer petit mais évolutif et allez loin.

Si je pars sur JBoss par exemple ca va me prendre du temps pour monter le serveur, comprendre les principes etc...

Je ne sais pas, je n'ai pas assez de recul pour trancher mais ceux sont la les désavantages directs que je vois...