Mailing List Archive

ntop and mysql update
ntop on RedHat on 7.1 using mysql DB update (option -b localhost:4000 and perl script related to UDP port 4000)

it works fine for very low traffic

as soon as the traffic becomes "larger", there is no updating of the TCPsessions table
( I get straight away 70% of the numTotSessions recorded - 23=0.07*32, device[i].numTotSessions=32 set in initialize.c)

any idea ?..
Re: ntop and mysql update [ In reply to ]
Didier Camino wrote:
>
> ntop on RedHat on 7.1 using mysql DB update (option -b localhost:4000 and perl script related to UDP port 4000)
>
> it works fine for very low traffic
>
> as soon as the traffic becomes "larger", there is no updating of the TCPsessions table
> ( I get straight away 70% of the numTotSessions recorded - 23=0.07*32, device[i].numTotSessions=32 set in initialize.c)
>
> any idea ?..

No, but I had the same thing here. I can't check it anymore because the
machine had a hardware crash. I noticed that after some time the
TCP-sessions come back again "automagically".

Richard.

--
___________________________________________________________________
Unix is very simple, but it takes a genius to understand the
simplicity (Dennis Ritchie)

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht, Linux 2.4.6 RedHat 6.2 |
| The Netherlands i686/300MHz/256MB |
| Public key: http://www.xs4all.nl/~pe1bbf/pubkey.asc |
+------------------------------------------------------------------+
RE: ntop and mysql update [ In reply to ]
One solution to the problem is to increase :
MAX_NUM_TCPSESSIONS (ntop.h) and
device[i].numTotSessions (initialize.c)
and to observe that the 70% limit is never reached (#sessions value display
on the screen for each new TCP session) by ntop when collecting data

I gave a try with (in my case both values set to 10 000 !!! and checked
that #session never went over 7000)
with this set up my TCPsessions table has been updated without any problem.

Anyway, It should be a better way to do it; what's going on in pbuf.c
(handleSession function ... if(sessionType == IPPROTO_TCP...else if
(theSession == NULL ..) we are in the case that a new TCP session is
detected then
a first test is done to enlarged the data anyway I do not think we can ever
reach it due to the test done just after (with a lower value for the test
"numTotsessions*0.7" instead of "numTotsessions*0.75" ) where the oldest
session are replaced

in other words we replace oldest sessions before trying to extend the TCP
hash : extendTcpUdpSessionHash() is never called
if we've got to keep it like that, shouldn't we update the TCPsessions
table with the session which is going to be replaced something like
notifyTCPsession(session to be replaced) ?

...........


-----Message d'origine-----
De: richard lucassen [SMTP:mailinglists@lucassen.org]
Date: mercredi 11 juillet 2001 12:52
A: ntop@unipi.it
Objet: Re: [Ntop] ntop and mysql update

Didier Camino wrote:
>
> ntop on RedHat on 7.1 using mysql DB update (option -b localhost:4000 and
perl script related to UDP port 4000)
>
> it works fine for very low traffic
>
> as soon as the traffic becomes "larger", there is no updating of the
TCPsessions table
> ( I get straight away 70% of the numTotSessions recorded - 23=0.07*32,
device[i].numTotSessions=32 set in initialize.c)
>
> any idea ?..

No, but I had the same thing here. I can't check it anymore because the
machine had a hardware crash. I noticed that after some time the
TCP-sessions come back again "automagically".

Richard.

--
___________________________________________________________________
Unix is very simple, but it takes a genius to understand the
simplicity (Dennis Ritchie)

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht, Linux 2.4.6 RedHat 6.2 |
| The Netherlands i686/300MHz/256MB |
| Public key: http://www.xs4all.nl/~pe1bbf/pubkey.asc |
+------------------------------------------------------------------+
_______________________________________________
Ntop mailing list
Ntop@unipi.it
http://listmanager.unipi.it/mailman/listinfo/ntop