http://scavenger.exa.org.uk/
C'est pas vraiment l'endroit mais bon ...
Tu scales a combien de capture ?
Le wrapper pour libpcap est en C donc la seule partie en Python c'est
le traitement des données. Comme dans le flots SMTP, le contenu du
mail est ignore, le traitement est donc _très_ rapide.
Et même Python n'est pas le langage le plus rapide du monde (ni de
loin le plus lent), c'est loin d'être un problème.
Parce que python c'est bien sympa mais
tu te prends tjs le lock global de l'interpréteur dans les dents dès
que
tu lui en demandes un peu trop, et donc de la latence dans le
runtime ...
Le Gloabl Lock n'est important que si le code est multi-threade (ce
qui n'est pas le cas), et comme la charge de travail est distribue
entre différents programmes, les cores du CPU sont correctement
utilise (merci le kernel :p)
De plus ce n'est pas une application "real time" (ou la latence est
importante) - si ca prends qque millisecondes de plus pour analyser un
paquet. Le code est aussi conçu pour supporter l'absence de packets
dans les flows. C'est pour cela que je peux concevoir intégrer netflow
plus tard (même si cela ne sera pas aussi efficace)
Il y a des cas ou le C (ou a defaut Java/C# pour leur VM) est
nécessaire, pour ce programme ce n'est pas trop le cas. Et comme les
programmes sont independants, il serai facile d'en replacer un avec un
version optimise si le cas devrait se montrer.
Maintenant, si qqun veut faire les tests, aucun problemes :D
Thomas
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
