- Define some fcns and vars as static;
- Use less generic names for certain externs;
Also: Remove some usused #defines & cleanup some whitespace
svn path=/trunk/; revision=34488
a protocol tree;
the column values.
This includes stats-tree listeners.
Have the routines to build the packet list, and to retap packets, honor
those requirements. This means that cf_retap_packets() no longer needs
an argument to specify whether to construct the column values or not, so
get rid of that argument.
This also means that there's no need for a tap to have a fake filter
to ensure that the protocol tree will be built, so don't set up a fake
"frame" filter.
While we're at it, clean up some cases where "no filter" was represented
as a null string rather than a null pointer.
Have a routine to return an indication of the number of tap listeners
with filters; use that rather than the global num_tap_filters.
Clean up some indentation and some gboolean vs. gint items.
svn path=/trunk/; revision=28645
#include winsock2.h pulls in about 90 distinct .h files
and about 140 total .h files.
Currently winsock2.h is (mostly unnecessarily) included
for each dissector via packet.h/wtap.h.
This patch removes #include winsock2.h from wtap.h and
then includes winsock2.h (or windows.h) in the
few specific places required.
With this patch, my Windows Wireshark build takes
about 30% less time.
svn path=/trunk/; revision=26535
unprotect_thread_critical_region() in every module in gtk/: instead have those
modules include main.h (which has the properly extern'd prototype).
This should fix the link error on HP-UX described in
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2702
svn path=/trunk/; revision=25933
libwireshark (and the plugins using those functions) do not depend on
wiretap on Windows.
While doing that, rename the eth_* functions to ws_*.
svn path=/trunk/; revision=25354
- Do not compare to the possibly resolved address, but the address itself
- Do not leak memory when comparing addresses
svn path=/trunk/; revision=24837
With the new feature we can:
1. Measure how big the bursts are for a video streams (it uses sliding window algorithm) 2. Measure how big the output buffer should be that no packet drop will occur (it uses Leaky bucket algorithm)
3. Detect if we have loses inside the MPEG2 video stream (if there are already MPEG2 packets missing) - this part of code is not added yet, see Limitations
The addition is called Multicast streams and works as follows:
- it uses the TAP system
- the main "stream" logic is taken from rtp_strems.* files
- the TAP system checks for UDP packets where the destination MAC address starts with "01:00:5E" (ethernet multicast address)
- it creates an entry for every new multicast stream
- based on sliding window and leaky bucket algorithm it calculates for every stream average BW, max BW, burst size, max buffer needed, some alarms if the limits are exceeded,...
- the same calculation is done for all streams together
- inside the window dialog you can specify the burst interval, the alarm limits and output speeds
To do & limitations:
- Currently the analysis can be done only for multicast streams, it means that VoD (Video on demand) or PayTV streams, which are normally unicast can not be analysed.
- since the MPEG2 is patended I don't know if decoding of MPEG2 packets is allowed? Can we look inside this packets and calculate packets drops based on some counter information inside the payload? Can someone please answer this question? If we can do this, I will post this part of code too.
- some more flexibility will be added
svn path=/trunk/; revision=17980