Saturday, 01-Feb-2003 0:49
Laurent DEHOEY, I177416, 16392@n0rg.org
| Name | Size | Date | ||
|---|---|---|---|---|
|
SimpleHttpd2.java | 14351 | 24/01/2003 |
Admin@TOSH-11K /cygdrive/c/Documents and Settings/Admin/Mes documents/16392/CDI/TP9/Q1 $ java SimpleHttpd2& [1] 1932 Admin@TOSH-11K /cygdrive/c/Documents and Settings/Admin/Mes documents/16392/CDI/TP9/Q1 $ telnet localhost 8080 Trying 127.0.0.1... Connected to TOSH-11K. Escape character is '^]'. GET / DaProtocolBlaBla Request: GET / DaProtocolBlaBla HTTP/1.0 200 OK Server: SimpleHttpd2 Content-Type: text/html Content-Length: 1102 .... ....de index.html page .... Connection closed by foreign host. Admin@TOSH-11K /cygdrive/c/Documents and Settings/Admin/Mes documents/16392/CDI/TP9/Q1 $ kill %1 Admin@TOSH-11K /cygdrive/c/Documents and Settings/Admin/Mes documents/16392/CDI/TP9/Q1 $ [1]+ Terminated java SimpleHttpd2 Admin@TOSH-11K /cygdrive/c/Documents and Settings/Admin/Mes documents/16392/CDI/TP9/Q1 $
La version des fichiers en 2.3 devra respecter toutes les specs...mais on est
train de faire les choses
donc voici une permiere version des sources qui "tournent" tous avec
les commandes de test en fin de TP
meme si on a pas de veritable certitude sur les choix de test et de gestion
des erreurs du serveur
o exécution: > java -cp TestServeurs.jar SimpleWeb8111Client localhost
et
o exécution: java -cp .;TestServeurs.jar TestServeurs ou java -cp .;TestServeurs.jar
TestServeurs http://localhost:8111/index.html http://localhost:8112/index.html
On met du random un peu partout pour générer des cas un peu limite
:
interrupt pendant un accept / interrupt pendant des requetes en cours/
prise en comptes de connections existantes. Sleeping de thread serveur
avec des temps plus long et plus cours que le accept. des temps de
traitement des clients plus ou moins long que les sleeping des thread
serveurs...
Ici on fait "exceptionner" le serveur si on tente de clore des connections
en cours
Le protocol http ici n'est pas implémenté : le serveur repond
sur le socket
ce qui le client lui à dit en rajoutant l'identité du thread servant
la requete
A ce stade je ne gere pas encore le pattern stratégy du protocol....c'est
la question d'apres
| Name | Size | Date | ||
|---|---|---|---|---|
 |
HttpProtocol.java | 7152 | 31/01/2003 | |
|
AbstractServer.java | 11058 | 31/01/2003 | |
|
Protocol.java | 313 | 31/01/2003 | |
|
Server.java | 2531 | 31/01/2003 | |
|
ClassicServer.java | 4190 | 31/01/2003 |
C'est un peu difficile de présenter une sortie d'ecran avec deux serveur et un client avec plusieurs thread qui attaquent ces deux serveurs jusqu'à ce qu'on le fasse planter sciemment
Admin@TOSH-11K /cygdrive/c/Documents and Settings/Admin/Mes documents/16392/CDI/TP8 $ Admin@TOSH-11K /cygdrive/c/Documents and Settings/Admin/Mes documents/16392/CDI/TP8 $
On a changé surtout dans ClassicServer.java toute la gestion du
retour vers le client par un seul appel : protocol.service(Socket client)
C'est plus clean
Il faut encore voir la gestion des erreurs, ca n'est pas fini : les plantages,
les temporistations les limitations du nombre de connections, les affichages
consoles sont à sérieusement revoir
| Name | Size | Date | ||
|---|---|---|---|---|
 |
HttpProtocol.java | 7131 | 31/01/2003 | |
|
AbstractServer.java | 11084 | 31/01/2003 | |
|
Protocol.java | 313 | 31/01/2003 | |
|
Server.java | 2531 | 31/01/2003 | |
|
ClassicServer.java | 4443 | 31/01/2003 | |
|
DaProcolarServars.jar | 2531 | 31/01/2003 |
En fait de la maniere dont on a procédé on a tout
depuis la question 2.2 Alors ici on va juste mettre
le jar et eventuellment plus tard des batteries de test
pour le fun de voir stresser notre serveur
Mais le DaProcolarServars.jar de la Q2.2 est plus
marrant à tester du coté client (on lui cause !)
| Name | Size | Date | ||
|---|---|---|---|---|
|
DaProcolarServars.jar | 7131 | 31/01/2003 |
"Most programs contain a multitude of methods, spread across a large number of classes. Of course, it's difficult, if not impossible, to test all of these methods from just the main entry point of a program.
That's why unit tests are useful. Many programmers and software designers (including myself) stress the usefulness of unit tests in writing robust software. But a potential tradeoff occurs if you want to be able to access the various elements of your program in a more interactive manner.
When this is the case, it can quickly become cumbersome to write, compile, and run new unit tests for each result. I find this especially true when I don't know in advance how my program will behave given certain inputs (as can be the case in an AI program, for instance).
So, what to do?"
http://www-106.ibm.com/developerworks/java/library/j-diag0312/
En fait j'ai eu du mal à interpréter ce que devait faire interrupt()
:
Il me semble que ce qui était demandé finalement était
de faire
une sorte de temporisation du serveur avec un sleep et ensuite
de le reveiller avec un interrupt ? Mais qui peut faire cet interrupt
du serveur lui meme ? un thread généré par le serveur ?
(j'ai trouvé cette référence trop tard dans "programmation
réseau
avec java" de E.R.Harold chez O'Reilly p137 de la deuxieme edition
en francais) Décidemment je n'arrive pas à me décider...
aussi
ai-je essayé de faire planter le serveur en pleine requete client
de manière aléatoire alors que j'ai tout pour eviter ca...
(connections,etc,..)
on aurait pu monter une petite applet avec un bouton d'interruption
du serveur pendant un laps de temps entré dans un champ de texte
Pour mon projet "routage dans les réseaux adhoc" je pense que
ces deux TP sur les threads vont peut-etre me servir : chaque
mobileun thread, avec ses propres paquets à envoyer/recevoir,
les paquets à router pour le compte de ses voisin, un thread
collecteur de statistiques, un thread collecteur de positions/vitesses
(la fonction
GPS)...
ca peut etre marrant ! :-)
This page was semi-automatically generated by SharpDevelop and a brain