From: Guy Harris
> On Jan 9, 2015, at 8:30 AM, Michael Richardson <m...@sandelman.ca> wrote:
>
> > Guy Harris <g...@alum.mit.edu> wrote:
> >> The longer timeout can reduce capturing overhead, and if you're
> >> capturing a high volume of traffic to a file, it's probably the right
> >> timeout to have.
If you are capturing a high volume of traffic even a short (10ms) timeout
won't expire.
> >> If, however, you're printing packets to the console,
> >> you're probably doomed if it's a high volume of traffic, and may want
> >> less of a delay if it's a low volume of traffic.
> >
> >> Should we reduce the timeout if -w isn't specified - or do so if -w
> >> isn't specified *and* if we're outputting to a terminal (isatty(1)
> >> returns a non-zero value)? Should we use immediate mode if libpcap
> >
> > Yes, I think that -w not specified, and isatty()==1.
What about piping through 'tee', 'grep' or into a pager?
In all those cases you want immediate output (as if directly writing the tty).
This also means you need an fflush(stdout) before waiting for more data.
Even with -w you can have problems - it is silly to have to wait a significant
time between running a test that generates a small number of packets and typing
^C to stop tcpdump.
>
> OK, I've implemented that for immediate mode, i.e. immediate mode if -w isn't
> specified and isatty(1)
> is true, and added a --immediate-mode flag so the nerds in the audience have
> a knob to tweak. :-)
>
> If pcap_set_immediate_mode() isn't available, should it set the timeout to a
> lower value instead, in
> those cases?
>
> Should we reduce the default timeout? Should we have a command-line flag to
> set the timeout?
I don't see any point in delaying more than 100ms.
Returning to user every 50ms shouldn't be a problem either.
David
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
