Publié le 14 Mars 2012

TCPDUMP permet d'effectuer une capture du traffic réseau sur une machine. La commande s'effectue avec la syntaxe suivante:

tcpdump -i <interface> -s 0 -n -w <fichier.cap> host <adresse IP> and port <port>

-i <interface> permet de spécifier l'interface à utiliser pour la capture. Pour connaitre le nom des interfaces on peut utiliser ifconfig.
-s 0 permet de capturer les trames complètes
-n n'effectue pas la résolution des noms (nécessite des adresses/ports sous forme numérique)
-w <fichier.cap> permet de capturer le traffic dans un fichier. L'extension .cap permet l'ouverture automatique avec wireshark. Si cette option n'est pas présente les trames sont affichées directement sur la console (via la sortie standard).

Ensuite le fichier .cap peut s'analyser plus ou moins facilement avec wireshark. 

Voir les commentaires

Rédigé par Bliz

Publié dans #Linux

Repost 0

Publié le 9 Mars 2012

Dans mon projet j'utilise un server Jetty embarqué pour pouvoir envoyer quelques requêtes HTTP et interrogé mon appli.

Le serveur n'est pas très solicité et donc il est configuré avec un thread pool de quelques threads seulement.

Je test sur mon PC local pas de problème, sur la machine de build non plus: tous les tests sont OK.

Super, c'est parti pour la mise en prod'. Et là le serveur démarre mais il ne traite plus aucune requête. La requête arrive au serveur mais il ne rend pas la main.

Bizarre... je jette un coup d'oeil dans les logs et je trouve la ligne suivante lors du démarrage du serveur:

oejs.AbstractConnector:insufficient threads configured for SelectChannelConnector@0.0.0.0:8080 STARTING

Mmmm ... je n'aurai pas assez de thread dans mon thread pool mais ça tournait très bien sur les machines de tests!

Un petit tour sur le net avec le message d'erreur mais je ne trouve pas beaucoup d'infos.

Du coup on tente un coup d'oeil dans le code source de Jetty: Et là surprise, dans le code du SelectChannelConector, on trouve:

setAcceptors(Math.max(1,(Runtime.getRuntime().availableProcessors()+3)/4));

Et oui la voilà la différence: en prod il y a beaucoup plus de core que dans nos environnements de tests! 

Il faut donc augmenter la taille du thread pool en conséquence ou spécifier explicitement le nombre d'acceptors avec

setAcceptors(nb);

Voir les commentaires

Rédigé par Bliz

Publié dans #Java

Repost 0

Publié le 7 Mars 2012

J'utilise Virtual Box pour avoir une machine windows sur mon PC dans laquelle je peux tester sous Internet Explorer. Virtual Box est bine sympa mais la configuration d'une VM (surtout la partie réseau) peut s'avérer compliqué quand on veut accèder à internet depuis la VM et accèder à la VM depuis le PC hôte.

Donc tout d'abord l'accès internet depuis la VM s'effectue dans la fenêtre "Settings"

Settings / Network / Adapter 1

Là il faut configurer:

Enable network adapter
Attached to NAT
Dans Advanced on peut laisser les options par défaut.

Ensuite pour configurer l'accès à la VM depuis l'hôte:

Il faut aller dans le menu principal de Virtual Box (pas dans celui de la VM - on peut également utiliser CTRL + G):

File / Preferences / Network

Là il faut ajouter un "host-only network" en utilisant:

IP address: 192.168.56.1 (qui est proposé par défaut par exemple)
On peut également configurer le serveur DHCP (optionnel mais penser à laisser de la place pour les IPs fixes).

Ensuite on revient aux settings de la  VM :

Settings / Network / Adapter 2 

pour créer un second network adapter pour l'accès depuis la machine hôte vers la VM.

Dans cet onglet il faut configurer:

Enable network adapter
Attached to Host-only Adapter
Name: vboxnet0 (vboxnet0 est normalement le nom du host-only network créé précédemment).
Dans "Advanced" on peut laisser les options par défaut.

Ensuite il faut démarrer la VM (Windows dans mon cas) puis dans les connexions réseaux, il faut configurer la 2e connexion pour utiliser une IP fixe comme 192.168.56.57 par exemple.

Voir les commentaires

Rédigé par Bliz

Publié dans #Linux

Repost 0

Publié le 5 Mars 2012

L'objet Date (bien que vivement critiqué) permet néanmoins de manipuler des dates du moment qu'on le considère comme un wrapper autour d'un long.

Ansi on peut facilement ajouter 2 dates en ajouter leur timestamps respectif:

Date now = new Date();
Date hour = new Date(3600*1000);
Date datetime = new Date(now.geTime() + hour.getTime());

datetime contient bien 1 heure de plus que l'heure actuelle.

Maintenant je dois récupérer ma date à partir d'un fichier texte. Ce fichier contient un champ date pour la date du jour et un champ time pour l'heure.

En utilisant SimpleDateFormat pour parser les dates et la méthode d'ajout de dates ci-dessus, ça donne:

Date date = new SimpleDateFormat("dd/MM/yyyy").parse("01/03/2012"); // au lieu de parser directement une chaine, j'utilise le champ date extrait du fichier
Date time = new SimpleDateFormat("hh:mm:ss").parse("14:05"33"); // même remarque
Date datetime = new Date(date.getTime() + time.getTime());

Et là j'imagine que datetime vaut "01/03/2012 14:05:33" mais en fait non ma date vaut "01/03/2012 13:05:33" soit une heure de moins que prévu.

En fait l'objet date correspond à un nombre de millisecondes écoulés depuis le 01/01/1970 GMT

Et c'est là que se situe le problème car SimpleDateFormat prend en compte la timezone lordqu'il parse une date. Hors actuellement nous sommes en GMT+1 ce qui explique l'heure de décallage.

Pour s'en rendre compte il suffit de faire:

System.out.println(new SimpleDateFormat("hh:mm:ss").parse("00:00:00").getTime()); // afficher -3600000 ms

On retrouve bien notre heure de décalage.

Pour y remedier il faut préciser qu'on veut utiliser la timezone GMT lorsqu'on parse l'heure:

Date time = new SimpleDateFormat("hh:mm:ss z").parse("14:05:33 GMT");

Voir les commentaires

Rédigé par Bliz

Publié dans #Java

Repost 0