Vendredi 24 juillet 2009

Nicolas R. m’a aidée à résoudre mon problème de thread ce matin. Cela était dû au fait que l’on mettait à jour un élément de l’interface graphique en-dehors du thread principal de SWT, ce qui provoquait un arrêt de l’application. Pour résoudre cela, il fallait utiliser les fonctions syncExec et asyncExec de l’objet Display. Malheureusement, lorsque le problème a été résolu, rien n’était streamé. Un flux était apparemment reçu, car une vignette vidéo apparaissait, mais aucune donnée ne semblait être transmise. J’ai donc revu mon code, et j’ai découvert de nombreuses erreurs d’implémentation. Le problème venait principalement du fait que j’indiquais les mauvais ports au serveur et aux récepteurs. J’ai donc corrigé tout cela,ce qui m’a pris un certain temps au vu de la complexité de ces tâches, mais j’ai finalement réussi à faire fonctionner le streaming vidéo.

Jeudi 23 juillet 2009

J’ai terminé les tests concernant le bon déroulement du processus de communication entre le serveur et les clients. Tous les messages sont bien envoyées et bien reçus, et les données récupérées sont les bonnes. Cependant, j’ai pu remarquer qu’un de mes messages était inutile. En effet, il lui manquait des données à transférer, mais ce travail était déjà effectué par un autre message, je l’ai donc remplacé par celui-ci. Il s’agit du message indiquant au client possesseur du flux vidéo à passer en mode focus qu’il doit augmenter le framerate de ce flux. Il lui manquait le nom du flux à passer en mode focus, étant donné qu’un client peut avoir plusieurs flux. Or le message signalant aux autres clients qu’ils doivent passer ce flux en mode focus effectue déjà ce type de travail, et étant donné que le premier client ne recevait jamais un message de ce type, je pouvais m’en servir pour cette opération.

Puis j’ai commencé à streamer les flux.Si on en croit les logs, les flux sont correctement envoyés et renvoyés, mais je n’arrive pas à les afficher pour le moment.

Mercredi 22 juillet 2009

Nicolas R. a déployé le serveur de l’application sur ma seconde machine et m’a aidée à ajouter mon plug-in à l’application principale. J’ai donc pu commencer à implémenter la classe principale de la partie cliente de mon plug-in, et effectuer des tests pour voir si elle communiquait bien avec la partie serveur. Lorsqu’on les teste l’un après l’autre et pris à part, tous les messages sont bien envoyés au serveur et il les reçoit correctement. La communication fonctionne également correctement dans l’autre sens. Qui-plus-est, les données sont correctement récupérées et dé-sérialisées. J’ai donc pu commencer à tester l’ensemble du processus de déclaration et de validation de flux.

Mardi 21 juillet 2009

Aujourd’hui, j’ai terminé la première ébauche de la partie serveur du plug-in. J’ai également effectué quelques tests, afin de voir si le message que j’avais modifié sérialisait et dé-sérialisait toujours bien les données, que le serveur récupérait bien ces données, ainsi que d’autres petits tests vérifiant certaines parties du système. Mais afin de pouvoir tester que l’envoi et le réception des messages s’effectue correctement côté serveur, je vais devoir installer un serveur sur une autre machine, et j’y ai donc installé Ubuntu.

Lundi 20 juillet 2009

J’ai poursuivi l’implémentation de la partie serveur du plug-in. J’ai demandé de l’aide à Nicolas R. afin de résoudre mes problèmes de protocole. En effet, la partie du protocole gérant le passage en mode focus d’une vidéo n’étant pas très bien établie, j’ai donc dû la revoir.

La partie de l’implémentation qui m’a posé le plus de problèmes reste cependant les messages de retour des différents clients, indiquant s’ils acceptent ou non le flux vidéo. En effet, les clients vers lesquels un flux est redirigé doivent être passés en paramètre dans un tableau, afin d’établir la configuration du MediaPlayer de ce flux. Il fallait donc remplir ce tableau au fur et à mesure que les clients répondent à la demande d’un flux, et une fois que tous les clients ont répondu, il fallait attribuer cette configuration au mediaPlayer afin qu’il leur retransmette les flux. J’ai donc crée une classe à part, DestinationsManager, afin de gérer cette partie. Autrement, l’implémentation serait devenue très compliquée et difficile à démêler.

Qui-plus-est, j’ai dû recoder la classe servant de message permettant au client d’accepter un flux vidéo. En effet, elle doit à présenter stipuler si le flux est acceptée ou non, ainsi que l’identifiant du flux qu’elle concerne.

Vendredi 17 juillet 2009

J’ai terminé les tests de mes messages. J’ai à présent pu commencer à implémenter la partie serveur du plug-in qui va répondre à ces messages. Au fur et à mesure de l’implémentation, des problèmes apparaissent, et je commence à me poser des questions en ce qui concerne certaines parties de mon protocole, car je ne suis pas sûre qu’elles soient parfaitement adaptées.

Jeudi 16 juillet 2009

Une coupure de courant dans la matinée m’a quelque peu freinée dans mon travail. L’après-midi, j’ai finalement dû déménager ma station de travail pour retrouver du courant et me remettre à coder.

J’ai donc commencé à tester les différents messages que j’ai implémentés la veille. Pour cela, Nicolas R. m’a fait savoir que je devais redéfinir les fonctions equals et hashcode de chacune de mes classes. En effet, en les redéfinissant, on s’assure ainsi que la fonction equals vérifiera les valeurs des attributs des objets afin de déterminer s’ils sont égaux, et pas simplement leur emplacement en mémoire. Ceci permet donc de vérifier que le message dé-sérialisé est identique (c’est-à-dire qu’il envoie les mêmes objets) au message avant sérialisation. La seule classe de messages envoyant des données qui me pose encore problème est la classe envoyant les informations sur les différents flux. En effet, lors de la dé-sérialisation de ces messages, les flux sont également reconstruits. Je pense qu’il faut également que je redéfinisse les fonction equals et hashcode dans la classe NamedStreamMedia que j’ai créée spécialement pour ces messages.

J’ai pu trouver comment redéfinir ces deux fonction sur le site suivant :

http://java.developpez.com/faq/java/?page=divers#DIVERS_hashCode

Mercredi 15 juillet 2009

Aujourd’hui, Nicolas R. a fait une dernière revue de schémas que j’ai réalisé afin de représenter le protocole de communication entre le serveur et les clients. J’ai ensuite dû développer les différents messages que vont s’échanger le serveur et les clients en créant une classe VideoSurveillanceMessage de laquelle vont hériter tous les différents messages. J’ai crée ainsi six classes différentes qui permettent, respectivement :

- à un client de déclarer un nombre N de flux au serveur
- au serveur d’accepter ces flux et de leurs attribuer N identifiants
- à un client de renvoyer la liste des informations concernant ses flux vidéo au serveur, ou au serveur d’accepter ces informations ou non et d’attribuer des ports à chaque flux
- à un client d’accepter un flux renvoyé par le serveur
- à un client de demander au serveur à ce qu’un flux diffusé par un autre client soit passé en mode focus
- au serveur de demander à cet autre client de créer un nouveau flux avec un framerate plus élevé

Vendredi 10 juillet 2009

Nicolas R. a revu mon code et mes diagrammes. J’ai apporté à mes diagrammes de séquences les corrections dont ils avaient besoin, et j’ai également réalisé les diagrammes représentant le protocole de communication entre le serveur et les clients.

Jeudi 9 juillet 2009

J’ai revu mes diagrammes de classes et de séquence afin de m’assurer qu’ils étaient corrects et complets. J’ai également achevé de commenter le code de façon détaillée.