Update of /export/home/ntop/ntop
In directory unknown:/tmp/cvs-serv20503
Modified Files:
address.c globals-core.c globals-core.h globals-defines.h
globals-structtypes.h hash.c http.c initialize.c leaks.c
main.c ntop.c ntop_win32.c pbuf.c plugin.c prefs.c
reportUtils.c ssl.c util.c webInterface.c
Log Message:
Replace the two ntop state indicators, capturePackets and endNtop, with
a single flag, ntopRunState;
Here's the skinny...
It's your classic state-transition table, tracking from preinit through term
(so someday we could restart). Flag values defined as usual in
globals-defines.h,
around lines 1620ff.
There is a routine to trap illegal transitions in globals-core.c,
_setRunState().
There is a one-time load of the permitted transition change table in there too.
_setRunState() also has (dummy) places - switch() statements - where we can
(and should) move a lot of the setup/cleanup logic. The 1st one is executed
based on the old state, the second switch based on the new state. So someday,
we could just cycle through the states and the setup/cleanup could happen
automatically.
The single state var allow a new routine, ntopSleepWhileSameState(), which
allows all of the sleep() loops to interrupt themselves if the state changes
(i.e. shutdown request). ntop won't shutdown immediately (that would take a
LOT of POSIX rework so each thread could be individually addressed by signals),
but rather at the next short (10s) interval, defined via #define
PARM_SLEEP_LIMIT.
There is also a routine, ntopSleepUntilStateRUN(), which loops in threads can
use
to wait until run state is reached. Things like fingerprint, idle purge, etc.
I choose to make the sniffer threads just start running - that way we get
packets
processing sooner.
The one thread which doesn't work is pcap_dispatch(). With the infinite
timeout,
if there really are no packets on the network, it will never return from that
function. But w/o putting a timeout and some form of polling in there, it
can't
be helped. S'be'it - ntop w/o packets over a 10s period is quite the edge case
anyway.
-----Burton (ref 597-a)
_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
