Ciao Paolo,
Paolo Lucente, 03.05.2006 16:41:
> On Wed, May 03, 2006 at 03:28:22PM +0200, Sven Anderson wrote:
>
>> Is there a case, when using the -r flag, where you don't want locking? Or
>> do you mean, that -l could be useful in case of not using -r?
>
> The latter. You can think at it like a macro-transaction. Now, multiple
> queries (ie. "80;21;20;22;53;25;443;*") are served in a shot (ok !) but
> are like micro-transaction. There could happen the unlikely case that,
> say, web traffic is catched by the first query (80); then, further web
> traffic arrive; then, it is catched and cleared by the last query (*).
^^^^^^^^^^^
If you don't use -r, there shouldn't be anything cleared. But I get your
point. There could be some port 80 packets in the * sum, which are not yet
in the port 80 sum. But that would be not so dramatic, as these packets
will be in the port 80 sum the next run, they are not "lost", just shifted
in time.
Ok, I'm a little bit confused now, so let me resume: There IS a locking,
but only if the -r flag is used. So this race condition cannot appear in
that case. When I'm using -r I don't have to worry, that port 80 packets
accidently drop into the "rest" (*) bin, correct?
>> BTW.: does the following error message refer to that locking?:
>> May 3 15:06:02 sniff pmacctd[16441]: ERROR ( dport/memory ): We are
>> missing data.
>
> No. It means that you are using too short plugin_pipe_size, buffer_size.
Sure. But I thought, the locking is maybe the cause for the buffers to
overflow.
Cheers,
Sven
--
Sven Anderson
Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de
Georg-August-Universitaet Goettingen
Lotzestr. 16-18, 37083 Goettingen, Germany
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
