str000mff a écrit 24 commentaires

plus exactement d'interdire tout systeme autre que windows chez les particuliers (pour les entreprises, on verra plus tard) ...

Bah quand j'utilise le client ssh par exempl, il s'en rend pas compte tout de suite chez moi... même si effectivement mon nm-applet du desktop le voit.

donc voila, je me dis qu'il doit y avoir un timer systeme qu'on peut regler...

++

Java c'est un language de haut niveau, tu ne manipules pas les IPCs directement
De mon point de vue les ipc pourrait etre utilisable de la JVM. Comment fait tu pour faire parler deux process java sur le meme host ensemble ? Par réseau... Mais pourquoi pas par les IPC si c'est sur la meme machine ?

Tu n'as certainement pas lu le lien que j'ai mis dans mon message...

non pas encore... mais je l'ai dans mes liens :)

Le java est pre-compilé (transformé en bytecode) et ensuite "optimisé" à l'exécution (JIT & co)... Toutes les optimisations que tu peux avoir lors d'une compilation sont transposables au bytecode...

oui c'est tout a fait ca... l'optimisation du bytecode dans ce cas ce fait au niveau de la JVM. Tu n'es donc plus responsable des optimisations systèmes en terme de compilation mais à l'execution...

Sauf qu'en C tu peux plus optimiser à la volée après vu qu'il n'y a pas de machine virtuelle.

evidamment il est optimisé avant (code & compil)...

Pour te donner un exemple, on a des parties de freenet écrit en assembleur (pour la crypto)... on a "vraiment" optimisé une section critique du code... pas le reste.

Voila une methode interessante que je serais retenir... Donc en gros la méthode Freenet ,en terme de méthodologie de développement, c'est tout faire en java et puis ensuite choper les partie de code qui ont des mauvaises perf pour les refaires en assembleurs. C'est bien ca ? L'integration de l'assembleurs avec une exec java ne pose pas trops de difficultés ? Pour la portabilités vous avez du galérer, non ? Pourquoi ne pas avoir choisi le C pour la crypto ?

Des gens qui savent pas coder codent dans tous les languages... dont le java, oui.

oui c'est clair. L'inconvenient du java c'est qu'il est beaucoup plus accessible et donc - de mon humble point de vue - la proportion des gens qui savent coder en java est plus faible que celle en C, d'abord parceque justement ils ne sont pas confrontés à toute les problématique pourri du C :)

Bon maintenant, pour ce qui est des développeurs qui ont fait bouffer 500Mo à la JVM, la question n'est pas tant qu'ils ne savent pas coder, la question est aussi le temps qu'on leur a donné pour faire leur bouzin. Une autre problématique du java, c'est que comme y'a plus besoin de réfléchir sur des probleme de portabilité les commandeur reduisent drastiquement les temps de développement... et parfois un peu trops :)

En quoi la "lourdeur du code" peut-elle avoir un impact quelconque sur les perfs ?

Et bien plus un code est lourd à l'utilisation plus j'estime que les développeur se sont compliqués la vie et plus on se complique la vie plus les perfs sont pourries (c'est l'une de mes regles).

Pour en revenir a l'exemple des fichiers - qui n'est qu'un exemple, si je me souviens bien en java y'a des objets input stream/ output stream alors quand C on parle juste de file descriptor. C'est cette utilisation des streams par exemple que je trouve compliqué pour atteindre un malheureux fichier... Mais peut etre ne suis je plus a jours ?

C'est pas propre au language ça.
non mais en fonction des languages tu peux trouver des lib/jar bien pratiques :)

"Tout dépend de la taille des messages à echanger, leur nombre, ..."

c'est justement là la question. :) En terme d'experience MOM, je ne connais actuellement pas de serveur d'echange de messages écrit en Java et qui aient pu détroner MQSeries en terme de perf...

"java n'est pas fondalementalement plus lent que le que le C"

pour moi fondamentalement il l'est. Le C est compilé (qui plus peut l'etre avec des options de compil specialement étudiée) et le java non. Mais dans la pratique tu as raison: cela dépend des développeurs :)

"mais si ton programme est bien écrit elle n'est chargée qu'une seule fois."

En fait pour le chargement de la JVM, ce n'est pas tellement ca qui me pose problème.

Ce qui me pose problème par exemple c'est la gestion cpu et mémoire - des developpeurs on reussit a faire utiliser 500 mo de mémoire à leur jvm pour l'affichage du suivi de 40000 transferts par exemple - peut etre n'utilisent ils pas correctement le GC ?

De plus je trouve l'acces fichier en java lourd en terme de code par rapport a ce qui se fait en C et donc en terme de perf je me dis que ca peut avoir un impact sur les perf ?

D' autres questions que je me posent c'est :

1) l'exploitation des ipc en java... d'apres mes connaissance actuelle elles ne sont tous simplement pas exploitable ?
2) l'exploitation des memoire flash... j'ai vu ici ou la des developpement java à ce propos, mais malheuresement aucun tutorial d'implementation par exemple....

Ok, je repond maintenant meme si j'ai trouvé la solution il y a maintenant qque temps.

Le code montré plus haut correspond en fait au code d'une api. la compilation de cette api utilisait bien l'option qu'il fallait et donc il n'y avais pas de PB au niveau de la librairie compilée.

Cependant pour le binaire qui appellait cette api, je n'avais pas mis l'option -D_XOPEN_SOURCE_EXTENDED - intentionnellement, puisqu'a priori dans le code du binaire je n'en avais pas vraiment besoin. Depuis que j'ai rajouté le -D_XOPEN_SOURCE_EXTENDED à la compil du binaire, je n'ai plus ce problème.

si tu regardes les traces tu verra que je suis bien dans le cas de la definition de _XOPEN_SOURCE_EXTENDED et que dans ce cas SOCKLEN = socklen_t :

+ 2007/07/16 11:57:36 _XOPEN_SOURCE_EXTENDED defined => SOCKLEN = socklen_t

par contre, tes deuxieme et troisieme remarques vallent bien que je jette un oeil plus approfondi au retour effectif de getsocklen et pas seulement au resultat dans ma sockaddr_in address... merci donc pour ton aide :)

Effectivement ca le fait nikel :) merci bcp :)

Bon j'ai eu des resultats interressant avec le SIGSTOP, cependant il faut penser à bien envoyer un SIGKILL sur les process parceque au bout d'un moment y'en à trops :) Mais enfin de compte, tant que ne les kill pas trops tot (en gros temps attente > timeout tcp), on a bien une mauvaise deconnexion. Du coup je n'ai meme pas essaillé de configurer mon firewall avec les flags TCP :)

oui, j'y ai pensé, mais ce test est aussi la pour charger le serveur autant que possible. Mon probleme est le suivant : bloquer uniquement le msg TCP fin pour ne pas empecher les nouvelles connections vers le serveur... je vais regarder un peu plus en detail iptables pour connaitre la syntaxe d'une telle regle...

merci pour tous tes conseils. j'avais effectivement pensé à débrancher la prise, mais comme c'est un test de charge je n'ai pas vraiment envie de brancher-rebrancher-brancher-rebrancher-brancher .... pour ce qui est de descendre l'interface, ce n'est pas une idée idiote - idée similaire : j'avais pensé à regler le firewall , mais comme mon petit tester a besoin de la connexion tout au long du test je ne pourrais pas m'en contenter. A mon avis la meilleur solution est donc de stop proprement les process, en esperant que derriere le noyau ne ferme pas proprement la socket. Je vais la tenter....

je vais tester des ce soir et je ferais un petit compte rendu ;)

astuce que je ne connaissais pas ;) mais comme tu peux t'en douter c'est effectivement sur le fichier avi en lui meme que je veux monter le son... merci quand meme :)

Pour ceux que ca interresse la solution pour selectionner les paquets crypté en SSL et capturé avec ethereal c'est d'appliquer le filtre suivant (display) :

(data[0]==17 or data[0]==16 or data[0]==15 or data[0]==14) and data[1]==3 and data[2]==1

notez qu'avec ca vous n'obtiendrez pas tous les paquets crypté SSL car il y a parfois des découpages lié à au couches inferieurs.

chez moi le && marche ;) mais encore une fois ct un filtre de display...

pour revenir à ma problematique, j'ai presque trouvé la reponse. Il faut savoir que dans le protocole SSL le premier byte reprend les valeurs suivantes : {14, 15, 16, 17} (état du handshake ssl). Ensuite vient la version sur les deux bytes suivant (03, 01 dans mon cas). Le problème desormait pour moi est de trouver la syntaxe tcpdump pour choper les trois premier bytes de la section data du paquet et de filtrer à partir de ca...

quelqu'un connait ?

oui excuse moi, c'est un filtre de display...

dans tout les cas filtrer le port 443 n'est pas une condition necessaire et suffisante pour l'utilisation de SSL. J'essai de trouver une regle ethereal qui me confirme l'utilisation de SSL quelque soit le port...

ah oui... c'est vrai que je n'y avais pas pensé :)

>mouais, je n'y crois pas trop à cette limitation debian. Je n'utilise pas
>une stable mais une sid et j'ai cela (j'ai bien 2 barrettes de 512 mo )...

en stable le noyau est en version 2.6.8 et je peus te confirmer qu' il y a bien une limitation. au niveau du noyau, on a l'option High Memory Support qui est à off.

Dans tout les cas je pense que meme pour une stable, cette option devrait être décoché.

>Sinon c'est quoi l'intéret d'utiliser une "stable" un peu obsolète en
>utilisation ordinateur de bureau ? (c'est une vraie question)

Comme je l'ai deja dit plus haut je fait de l'ogg streaming (Icecast) et surtout j'ai ouvert un serveur apache sur un nom de domaine dedie, ma machine n'est pas seulement un ordinateur de bureau mais joue surtout le role d'un mini serveur qui a son lot d'attaque bot quotidien. Je sais que le mieux serait de dedier une machine speciale, mais je n'en ai pas encore les moyens. Donc voila je "compromise" :)

je suis completement equitable. Par definition lorsque tu installes une debian tu ne la reinstalle plus, tu l'upgrade. Donc la date de sortie de la distrib importe peu.

Hors il est très clair que pour la debian stable, les mises à jours des paquets sont bcp plus lente que sur la testing ou la unstable.

Ce qui m'ennui, c'est que du cote d'Ubuntu les mises à jours des paquets sur la version stable est plus rapide et colle plus à l'évolution des besoins. Bref Debian semble dépassée de ce côté, meme si on peut supposer que pour la version stable, la debian sera plus stable que la ubuntu.

> ça serait vraiment bizarre que cette option n'y soit pas activée par défaut.

c'est effectivement tres bizzard, mais c'est le cas ! j'utilise bien le noyau officiel fourni par debian .... et pourtant, celui ci limite l'utilisation de la memoire à moins de 800 MO. C'est quand meme un mauvais point pour debian surtout qu'ubuntu ne pose pas ce probleme. Enfin, on est stable ou pas, et je suis parti pour recompiler le noyau. Merci bien pour ton aide !

:) pas mal aussi ce scripts. J'aime bien l'idee de m'endormir en musique - meme si je ne compte pas eteindre le pc sinon j'ai plus de reveil...

merci à tous en tous cas pour vos réponses !!!

Comme le précise la fin du man :

To get the prototypes under glibc, define both _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED, or use "#define _XOPEN_SOURCE n" for some integer n larger than or equal to 500.

Il ne s'agit donc plus de _GNU_SOURCE mais de _XOPEN_SOURCE. Bref, l'évolution de unistd.h n'a pas été faite en pensant aux vieux codes sources et à la portabilité ... C'est vraiment dommage :/

héhé, faut lire le man jusqu'au bout ... ;)

en tout cas ca rend le truc pas tres beau parceque sous sun ou freebsd y'a pas besoin de ca ... et ca pourri la portabilité. :/

man getpid :

NAME
setpgid, getpgid, setpgrp, getpgrp - set/get process group

SYNOPSIS
#include <unistd.h>

int setpgid(pid_t pid, pid_t pgid);
pid_t getpgid(pid_t pid);
int setpgrp(void);
pid_t getpgrp(void);

...

:/