- 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
1) This indicates that the string has ephemeral lifetime
2) More consistent with its existing seasonal counterpart, se_address_to_str().
svn path=/trunk/; revision=29747
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
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
Bill Meier