From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
/* mcast_stream.c
|
|
|
|
*
|
|
|
|
* Copyright 2006, Iskratel , Slovenia
|
2008-05-22 15:46:27 +00:00
|
|
|
* By Jakob Bratkovic <j.bratkovic@iskratel.si> and
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
* Miha Jemec <m.jemec@iskratel.si>
|
|
|
|
*
|
|
|
|
* based on rtp_stream.c
|
|
|
|
* Copyright 2003, Alcatel Business Systems
|
|
|
|
* By Lars Ruoff <lars.ruoff@gmx.net>
|
|
|
|
*
|
2006-05-21 05:12:17 +00:00
|
|
|
* Wireshark - Network traffic analyzer
|
|
|
|
* By Gerald Combs <gerald@wireshark.org>
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
* Copyright 1998 Gerald Combs
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
2012-06-28 22:56:06 +00:00
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
*/
|
|
|
|
|
2012-09-20 01:48:30 +00:00
|
|
|
#include "config.h"
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
2010-10-12 16:05:19 +00:00
|
|
|
#include <glib.h>
|
|
|
|
|
2009-08-27 04:47:28 +00:00
|
|
|
#include <stdio.h>
|
2013-11-10 15:59:37 +00:00
|
|
|
#include <stdlib.h>
|
2008-04-13 03:32:24 +00:00
|
|
|
#include <time.h>
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
#include <string.h>
|
2008-04-13 03:32:24 +00:00
|
|
|
|
2014-10-27 22:00:54 +00:00
|
|
|
#include "file.h"
|
2008-04-13 03:32:24 +00:00
|
|
|
|
|
|
|
#include <epan/epan.h>
|
2010-10-12 16:05:19 +00:00
|
|
|
#include <epan/address.h>
|
2008-04-13 03:32:24 +00:00
|
|
|
#include <epan/packet.h>
|
|
|
|
#include <epan/tap.h>
|
2013-11-10 09:44:02 +00:00
|
|
|
#include <epan/to_str.h>
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
2012-01-16 01:07:52 +00:00
|
|
|
#include "ui/alert_box.h"
|
2014-10-27 22:00:54 +00:00
|
|
|
#include "ui/mcast_stream.h"
|
2012-01-16 01:07:52 +00:00
|
|
|
#include "ui/simple_dialog.h"
|
2008-04-13 03:32:24 +00:00
|
|
|
|
2010-10-12 16:05:19 +00:00
|
|
|
gint32 mcast_stream_trigger = 50; /* limit for triggering the burst alarm (in packets per second) */
|
2015-02-01 20:57:30 +00:00
|
|
|
gint32 mcast_stream_bufferalarm = 10000; /* limit for triggering the buffer alarm (in bytes) */
|
2010-10-12 16:05:19 +00:00
|
|
|
guint16 mcast_stream_burstint = 100; /* burst interval in ms */
|
|
|
|
gint32 mcast_stream_emptyspeed = 5000; /* outgoing speed for single stream (kbps)*/
|
|
|
|
gint32 mcast_stream_cumulemptyspeed = 100000; /* outgoiong speed for all streams (kbps)*/
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
|
|
|
/* sliding window and buffer usage */
|
2010-10-12 16:05:19 +00:00
|
|
|
static gint32 buffsize = (int)((double)MAX_SPEED * 100 / 1000) * 2;
|
2015-05-16 20:48:04 +00:00
|
|
|
static guint16 comparetimes(nstime_t *t1, nstime_t *t2, guint16 burstint_lcl);
|
2010-10-12 16:05:19 +00:00
|
|
|
static void buffusagecalc(mcast_stream_info_t *strinfo, packet_info *pinfo, double emptyspeed_lcl);
|
|
|
|
static void slidingwindow(mcast_stream_info_t *strinfo, packet_info *pinfo);
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
/* GCompareFunc style comparison function for _mcast_stream_info */
|
2010-10-12 16:05:19 +00:00
|
|
|
static gint
|
|
|
|
mcast_stream_info_cmp(gconstpointer aa, gconstpointer bb)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2014-11-16 15:28:51 +00:00
|
|
|
const struct _mcast_stream_info* a = (const struct _mcast_stream_info *)aa;
|
|
|
|
const struct _mcast_stream_info* b = (const struct _mcast_stream_info *)bb;
|
|
|
|
|
|
|
|
if (a==b)
|
|
|
|
return 0;
|
|
|
|
if (a==NULL || b==NULL)
|
|
|
|
return 1;
|
2015-10-21 18:46:49 +00:00
|
|
|
if (addresses_equal(&(a->src_addr), &(b->src_addr))
|
2014-11-16 15:28:51 +00:00
|
|
|
&& (a->src_port == b->src_port)
|
2015-10-21 18:46:49 +00:00
|
|
|
&& addresses_equal(&(a->dest_addr), &(b->dest_addr))
|
2014-11-16 15:28:51 +00:00
|
|
|
&& (a->dest_port == b->dest_port))
|
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
return 1;
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
/* when there is a [re]reading of packet's */
|
2010-10-12 16:05:19 +00:00
|
|
|
void
|
|
|
|
mcaststream_reset(mcaststream_tapinfo_t *tapinfo)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2014-11-16 15:28:51 +00:00
|
|
|
GList* list;
|
|
|
|
|
|
|
|
/* free the data items first */
|
|
|
|
list = g_list_first(tapinfo->strinfo_list);
|
|
|
|
while (list)
|
|
|
|
{
|
|
|
|
/* XYZ I don't know how to clean this */
|
|
|
|
/*g_free(list->element.buff); */
|
|
|
|
g_free(list->data);
|
|
|
|
list = g_list_next(list);
|
|
|
|
}
|
|
|
|
g_list_free(tapinfo->strinfo_list);
|
|
|
|
tapinfo->strinfo_list = NULL;
|
|
|
|
|
|
|
|
/* XYZ and why does the line below causes a crach? */
|
|
|
|
/*g_free(tapinfo->allstreams->element.buff);*/
|
|
|
|
g_free(tapinfo->allstreams);
|
|
|
|
tapinfo->allstreams = NULL;
|
|
|
|
|
|
|
|
tapinfo->npackets = 0;
|
|
|
|
|
|
|
|
return;
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
2010-10-12 16:05:19 +00:00
|
|
|
static void
|
2015-08-12 21:09:35 +00:00
|
|
|
mcaststream_reset_cb(void *ti_ptr)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2015-08-12 21:09:35 +00:00
|
|
|
mcaststream_tapinfo_t *tapinfo = (mcaststream_tapinfo_t *)ti_ptr;
|
2015-08-24 08:29:18 +00:00
|
|
|
if (tapinfo) {
|
|
|
|
if (tapinfo->tap_reset) {
|
2015-11-27 16:57:34 +00:00
|
|
|
tapinfo->tap_reset(tapinfo);
|
2015-08-24 08:29:18 +00:00
|
|
|
}
|
|
|
|
mcaststream_reset(tapinfo);
|
2015-08-12 21:09:35 +00:00
|
|
|
}
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
/* redraw the output */
|
2010-10-12 16:05:19 +00:00
|
|
|
static void
|
2014-10-27 22:00:54 +00:00
|
|
|
mcaststream_draw(void *ti_ptr)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2014-10-27 22:00:54 +00:00
|
|
|
mcaststream_tapinfo_t *tapinfo = (mcaststream_tapinfo_t *)ti_ptr;
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
/* XXX: see mcaststream_on_update in mcast_streams_dlg.c for comments
|
2014-11-16 15:28:51 +00:00
|
|
|
g_signal_emit_by_name(top_level, "signal_mcaststream_update");
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
*/
|
2014-10-27 22:00:54 +00:00
|
|
|
if (tapinfo && tapinfo->tap_draw) {
|
2015-11-27 16:57:34 +00:00
|
|
|
tapinfo->tap_draw(tapinfo);
|
2014-10-27 22:00:54 +00:00
|
|
|
}
|
2014-11-16 15:28:51 +00:00
|
|
|
return;
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
/* whenever a udp packet is seen by the tap listener */
|
2015-08-12 21:09:35 +00:00
|
|
|
static gboolean
|
2010-10-12 16:05:19 +00:00
|
|
|
mcaststream_packet(void *arg, packet_info *pinfo, epan_dissect_t *edt _U_, const void *arg2 _U_)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2014-11-16 15:28:51 +00:00
|
|
|
mcaststream_tapinfo_t *tapinfo = (mcaststream_tapinfo_t *)arg;
|
|
|
|
mcast_stream_info_t tmp_strinfo;
|
|
|
|
mcast_stream_info_t *strinfo = NULL;
|
|
|
|
GList* list;
|
2015-05-16 20:48:04 +00:00
|
|
|
nstime_t delta;
|
|
|
|
double deltatime;
|
2014-11-16 15:28:51 +00:00
|
|
|
|
2015-08-12 22:11:39 +00:00
|
|
|
/*
|
|
|
|
* Restrict statistics to standard multicast IPv4 and IPv6 addresses.
|
|
|
|
* We might want to check for and allow ethernet addresses starting
|
|
|
|
* with 01:00:05 and 33:33 as well.
|
|
|
|
*/
|
|
|
|
switch (pinfo->net_dst.type) {
|
|
|
|
case AT_IPv4:
|
|
|
|
/* 224.0.0.0/4 */
|
|
|
|
if (pinfo->net_dst.len == 0 || (((const guint8*)pinfo->net_dst.data)[0] & 0xf0) != 0xe0)
|
|
|
|
return FALSE;
|
|
|
|
break;
|
|
|
|
case AT_IPv6:
|
|
|
|
/* ff00::/8 */
|
|
|
|
/* XXX This includes DHCPv6. */
|
|
|
|
if (pinfo->net_dst.len == 0 || ((const guint8*)pinfo->net_dst.data)[0] != 0xff)
|
|
|
|
return FALSE;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2014-11-16 15:28:51 +00:00
|
|
|
/* gather infos on the stream this packet is part of */
|
2015-10-21 18:46:49 +00:00
|
|
|
copy_address(&(tmp_strinfo.src_addr), &(pinfo->net_src));
|
2014-11-16 15:28:51 +00:00
|
|
|
tmp_strinfo.src_port = pinfo->srcport;
|
2015-10-21 18:46:49 +00:00
|
|
|
copy_address(&(tmp_strinfo.dest_addr), &(pinfo->net_dst));
|
2014-11-16 15:28:51 +00:00
|
|
|
tmp_strinfo.dest_port = pinfo->destport;
|
|
|
|
|
|
|
|
/* check whether we already have a stream with these parameters in the list */
|
|
|
|
list = g_list_first(tapinfo->strinfo_list);
|
|
|
|
while (list)
|
|
|
|
{
|
|
|
|
if (mcast_stream_info_cmp(&tmp_strinfo, (mcast_stream_info_t*)(list->data))==0)
|
|
|
|
{
|
|
|
|
strinfo = (mcast_stream_info_t*)(list->data); /*found!*/
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
list = g_list_next(list);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* not in the list? then create a new entry */
|
|
|
|
if (!strinfo) {
|
2015-01-05 02:40:05 +00:00
|
|
|
/*printf("nov sip %s sp %d dip %s dp %d\n", address_to_display(NULL, &(pinfo->src)),
|
|
|
|
pinfo->srcport, address_to_display(NULL, &(pinfo->dst)), pinfo->destport);*/
|
2014-11-16 15:28:51 +00:00
|
|
|
tmp_strinfo.npackets = 0;
|
|
|
|
tmp_strinfo.apackets = 0;
|
|
|
|
tmp_strinfo.first_frame_num = pinfo->fd->num;
|
2015-05-16 20:48:04 +00:00
|
|
|
tmp_strinfo.start_abs = pinfo->fd->abs_ts;
|
|
|
|
tmp_strinfo.start_rel = pinfo->rel_ts;
|
2014-11-16 15:28:51 +00:00
|
|
|
tmp_strinfo.vlan_id = 0;
|
|
|
|
|
|
|
|
/* reset Mcast stats */
|
|
|
|
tmp_strinfo.average_bw = 0;
|
|
|
|
tmp_strinfo.total_bytes = 0;
|
|
|
|
|
|
|
|
/* reset slidingwindow and buffer parameters */
|
2015-05-16 20:48:04 +00:00
|
|
|
tmp_strinfo.element.buff = (nstime_t *)g_malloc(buffsize * sizeof(nstime_t));
|
2014-11-16 15:28:51 +00:00
|
|
|
tmp_strinfo.element.first=0;
|
|
|
|
tmp_strinfo.element.last=0;
|
|
|
|
tmp_strinfo.element.burstsize=1;
|
|
|
|
tmp_strinfo.element.topburstsize=1;
|
|
|
|
tmp_strinfo.element.numbursts=0;
|
|
|
|
tmp_strinfo.element.burststatus=0;
|
|
|
|
tmp_strinfo.element.count=1;
|
|
|
|
tmp_strinfo.element.buffusage=pinfo->fd->pkt_len;
|
|
|
|
tmp_strinfo.element.topbuffusage=pinfo->fd->pkt_len;
|
|
|
|
tmp_strinfo.element.numbuffalarms=0;
|
|
|
|
tmp_strinfo.element.buffstatus=0;
|
|
|
|
tmp_strinfo.element.maxbw=0;
|
|
|
|
|
|
|
|
strinfo = (mcast_stream_info_t *)g_malloc(sizeof(mcast_stream_info_t));
|
|
|
|
*strinfo = tmp_strinfo; /* memberwise copy of struct */
|
|
|
|
tapinfo->strinfo_list = g_list_append(tapinfo->strinfo_list, strinfo);
|
2015-05-16 20:48:04 +00:00
|
|
|
strinfo->element.buff = (nstime_t *)g_malloc(buffsize * sizeof(nstime_t));
|
2014-11-16 15:28:51 +00:00
|
|
|
|
|
|
|
/* set time with the first packet */
|
|
|
|
if (tapinfo->npackets == 0) {
|
|
|
|
tapinfo->allstreams = (mcast_stream_info_t *)g_malloc(sizeof(mcast_stream_info_t));
|
|
|
|
tapinfo->allstreams->element.buff =
|
2015-05-16 20:48:04 +00:00
|
|
|
(nstime_t *)g_malloc(buffsize * sizeof(nstime_t));
|
|
|
|
tapinfo->allstreams->start_rel = pinfo->rel_ts;
|
2014-11-16 15:28:51 +00:00
|
|
|
tapinfo->allstreams->total_bytes = 0;
|
|
|
|
tapinfo->allstreams->element.first=0;
|
|
|
|
tapinfo->allstreams->element.last=0;
|
|
|
|
tapinfo->allstreams->element.burstsize=1;
|
|
|
|
tapinfo->allstreams->element.topburstsize=1;
|
|
|
|
tapinfo->allstreams->element.numbursts=0;
|
|
|
|
tapinfo->allstreams->element.burststatus=0;
|
|
|
|
tapinfo->allstreams->element.count=1;
|
|
|
|
tapinfo->allstreams->element.buffusage=pinfo->fd->pkt_len;
|
|
|
|
tapinfo->allstreams->element.topbuffusage=pinfo->fd->pkt_len;
|
|
|
|
tapinfo->allstreams->element.numbuffalarms=0;
|
|
|
|
tapinfo->allstreams->element.buffstatus=0;
|
|
|
|
tapinfo->allstreams->element.maxbw=0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* time between first and last packet in the group */
|
2015-05-16 20:48:04 +00:00
|
|
|
strinfo->stop_rel = pinfo->rel_ts;
|
|
|
|
nstime_delta(&delta, &strinfo->stop_rel, &strinfo->start_rel);
|
|
|
|
deltatime = nstime_to_sec(&delta);
|
2014-11-16 15:28:51 +00:00
|
|
|
|
|
|
|
/* calculate average bandwidth for this stream */
|
|
|
|
strinfo->total_bytes = strinfo->total_bytes + pinfo->fd->pkt_len;
|
|
|
|
|
|
|
|
/* increment the packets counter for this stream and calculate average pps */
|
|
|
|
++(strinfo->npackets);
|
2015-08-12 21:09:35 +00:00
|
|
|
|
|
|
|
if (deltatime > 0) {
|
|
|
|
strinfo->apackets = strinfo->npackets / deltatime;
|
|
|
|
strinfo->average_bw = ((double)(strinfo->total_bytes*8) / deltatime);
|
|
|
|
} else {
|
|
|
|
strinfo->apackets = strinfo->average_bw = 0.0;
|
|
|
|
}
|
2014-11-16 15:28:51 +00:00
|
|
|
|
|
|
|
/* time between first and last packet in any group */
|
2015-05-16 20:48:04 +00:00
|
|
|
tapinfo->allstreams->stop_rel = pinfo->rel_ts;
|
|
|
|
nstime_delta(&delta, &tapinfo->allstreams->stop_rel, &tapinfo->allstreams->start_rel);
|
|
|
|
deltatime = nstime_to_sec(&delta);
|
2014-11-16 15:28:51 +00:00
|
|
|
|
|
|
|
/* increment the packets counter of all streams */
|
|
|
|
++(tapinfo->npackets);
|
|
|
|
|
|
|
|
/* calculate average bandwidth for all streams */
|
|
|
|
tapinfo->allstreams->total_bytes = tapinfo->allstreams->total_bytes + pinfo->fd->pkt_len;
|
|
|
|
if (deltatime > 0)
|
2015-08-12 21:09:35 +00:00
|
|
|
tapinfo->allstreams->average_bw = ((double)(tapinfo->allstreams->total_bytes*8) / deltatime);
|
2014-11-16 15:28:51 +00:00
|
|
|
|
|
|
|
/* sliding window and buffercalc for this group*/
|
|
|
|
slidingwindow(strinfo, pinfo);
|
|
|
|
buffusagecalc(strinfo, pinfo, mcast_stream_emptyspeed*1000);
|
|
|
|
/* sliding window and buffercalc for all groups */
|
|
|
|
slidingwindow(tapinfo->allstreams, pinfo);
|
|
|
|
buffusagecalc(tapinfo->allstreams, pinfo, mcast_stream_cumulemptyspeed*1000);
|
|
|
|
/* end of sliding window */
|
|
|
|
|
|
|
|
return 1; /* refresh output */
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
/* scan for Mcast streams */
|
2010-10-12 16:05:19 +00:00
|
|
|
void
|
2014-10-27 22:00:54 +00:00
|
|
|
mcaststream_scan(mcaststream_tapinfo_t *tapinfo, capture_file *cap_file)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2014-10-27 22:00:54 +00:00
|
|
|
gboolean was_registered;
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
2014-10-27 22:00:54 +00:00
|
|
|
if (!tapinfo || !cap_file) {
|
|
|
|
return;
|
|
|
|
}
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
2014-10-27 22:00:54 +00:00
|
|
|
was_registered = tapinfo->is_registered;
|
|
|
|
if (!tapinfo->is_registered)
|
|
|
|
register_tap_listener_mcast_stream(tapinfo);
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
2014-10-27 22:00:54 +00:00
|
|
|
cf_retap_packets(cap_file);
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
|
2014-10-27 22:00:54 +00:00
|
|
|
if (!was_registered)
|
|
|
|
remove_tap_listener_mcast_stream(tapinfo);
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
/* TAP INTERFACE */
|
|
|
|
/****************************************************************************/
|
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
void
|
2014-10-27 22:00:54 +00:00
|
|
|
remove_tap_listener_mcast_stream(mcaststream_tapinfo_t *tapinfo)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2014-10-27 22:00:54 +00:00
|
|
|
if (tapinfo && tapinfo->is_registered) {
|
|
|
|
remove_tap_listener(tapinfo);
|
|
|
|
tapinfo->is_registered = FALSE;
|
2014-11-16 15:28:51 +00:00
|
|
|
}
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/****************************************************************************/
|
|
|
|
void
|
2014-10-27 22:00:54 +00:00
|
|
|
register_tap_listener_mcast_stream(mcaststream_tapinfo_t *tapinfo)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2014-11-16 15:28:51 +00:00
|
|
|
GString *error_string;
|
2014-10-27 22:00:54 +00:00
|
|
|
|
|
|
|
if (!tapinfo) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!tapinfo->is_registered) {
|
|
|
|
error_string = register_tap_listener("udp", tapinfo,
|
2014-11-16 15:28:51 +00:00
|
|
|
NULL, 0, mcaststream_reset_cb, mcaststream_packet,
|
|
|
|
mcaststream_draw);
|
|
|
|
|
|
|
|
if (error_string != NULL) {
|
|
|
|
simple_dialog(ESD_TYPE_ERROR, ESD_BTN_OK,
|
|
|
|
"%s", error_string->str);
|
|
|
|
g_string_free(error_string, TRUE);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2014-10-27 22:00:54 +00:00
|
|
|
tapinfo->is_registered = TRUE;
|
2014-11-16 15:28:51 +00:00
|
|
|
}
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*******************************************************************************/
|
|
|
|
/* sliding window and buffer calculations */
|
|
|
|
|
|
|
|
/* compare two times */
|
2010-10-12 16:05:19 +00:00
|
|
|
static guint16
|
2015-05-16 20:48:04 +00:00
|
|
|
comparetimes(nstime_t *t1, nstime_t *t2, guint16 burstint_lcl)
|
2010-10-12 16:05:19 +00:00
|
|
|
{
|
2015-05-16 20:48:04 +00:00
|
|
|
if(((t2->secs - t1->secs)*1000 + (t2->nsecs - t1->nsecs)/1000000) > burstint_lcl){
|
2014-11-16 15:28:51 +00:00
|
|
|
return 1;
|
|
|
|
} else{
|
|
|
|
return 0;
|
|
|
|
}
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* calculate buffer usage */
|
2010-10-12 16:05:19 +00:00
|
|
|
static void
|
|
|
|
buffusagecalc(mcast_stream_info_t *strinfo, packet_info *pinfo, double emptyspeed_lcl)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2015-05-16 20:48:04 +00:00
|
|
|
gint32 cur, prev;
|
|
|
|
nstime_t *buffer;
|
|
|
|
nstime_t delta;
|
2014-11-16 15:28:51 +00:00
|
|
|
double timeelapsed;
|
|
|
|
|
|
|
|
buffer = strinfo->element.buff;
|
|
|
|
cur = strinfo->element.last;
|
|
|
|
if(cur == 0){
|
|
|
|
cur = buffsize - 1;
|
|
|
|
prev = cur - 1;
|
|
|
|
} else if(cur == 1){
|
|
|
|
prev = buffsize - 1;
|
|
|
|
cur = 0;
|
|
|
|
} else{
|
|
|
|
cur=cur-1;
|
|
|
|
prev=cur-1;
|
|
|
|
}
|
|
|
|
|
2015-05-16 20:48:04 +00:00
|
|
|
nstime_delta(&delta, &buffer[cur], &buffer[prev]);
|
|
|
|
timeelapsed = nstime_to_sec(&delta);
|
2014-11-16 15:28:51 +00:00
|
|
|
|
|
|
|
/* bytes added to buffer */
|
|
|
|
strinfo->element.buffusage+=pinfo->fd->pkt_len;
|
|
|
|
|
|
|
|
/* bytes cleared from buffer */
|
|
|
|
strinfo->element.buffusage-= (guint32) (timeelapsed * emptyspeed_lcl / 8);
|
|
|
|
|
|
|
|
if(strinfo->element.buffusage < 0) strinfo->element.buffusage=0;
|
|
|
|
if(strinfo->element.buffusage > strinfo->element.topbuffusage)
|
|
|
|
strinfo->element.topbuffusage = strinfo->element.buffusage;
|
|
|
|
/* check for buffer losses */
|
|
|
|
if((strinfo->element.buffusage >= mcast_stream_bufferalarm) && (strinfo->element.buffstatus == 0)){
|
|
|
|
strinfo->element.buffstatus = 1;
|
|
|
|
strinfo->element.numbuffalarms++;
|
|
|
|
} else if(strinfo->element.buffusage < mcast_stream_bufferalarm){
|
|
|
|
strinfo->element.buffstatus = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* sliding window calculation */
|
2010-10-12 16:05:19 +00:00
|
|
|
static void
|
|
|
|
slidingwindow(mcast_stream_info_t *strinfo, packet_info *pinfo)
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
{
|
2015-05-16 20:48:04 +00:00
|
|
|
nstime_t *buffer;
|
2014-11-16 15:28:51 +00:00
|
|
|
gint32 diff;
|
|
|
|
|
|
|
|
buffer = strinfo->element.buff;
|
|
|
|
|
|
|
|
diff = strinfo->element.last - strinfo->element.first;
|
|
|
|
if(diff < 0) diff+=buffsize;
|
|
|
|
|
|
|
|
/* check if buffer is full */
|
|
|
|
if(diff >= (buffsize - 2)){
|
|
|
|
fprintf(stderr, "Warning: capture buffer full\n");
|
|
|
|
strinfo->element.first++;
|
|
|
|
if(strinfo->element.first >= buffsize) strinfo->element.first = strinfo->element.first % buffsize;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* burst count */
|
2015-05-16 20:48:04 +00:00
|
|
|
buffer[strinfo->element.last] = pinfo->rel_ts;
|
|
|
|
while(comparetimes(&buffer[strinfo->element.first],
|
|
|
|
&buffer[strinfo->element.last], mcast_stream_burstint)){
|
2014-11-16 15:28:51 +00:00
|
|
|
strinfo->element.first++;
|
|
|
|
if(strinfo->element.first >= buffsize) strinfo->element.first = strinfo->element.first % buffsize;
|
|
|
|
diff--;
|
|
|
|
}
|
|
|
|
strinfo->element.burstsize = diff;
|
|
|
|
if(strinfo->element.burstsize > strinfo->element.topburstsize) {
|
|
|
|
strinfo->element.topburstsize = strinfo->element.burstsize;
|
2015-08-12 21:09:35 +00:00
|
|
|
strinfo->element.maxbw = (double)(strinfo->element.topburstsize) * 1000 / mcast_stream_burstint * pinfo->fd->pkt_len * 8;
|
2014-11-16 15:28:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
strinfo->element.last++;
|
|
|
|
if(strinfo->element.last >= buffsize) strinfo->element.last = strinfo->element.last % buffsize;
|
|
|
|
/* trigger check */
|
|
|
|
if((strinfo->element.burstsize >= mcast_stream_trigger) && (strinfo->element.burststatus == 0)){
|
|
|
|
strinfo->element.burststatus = 1;
|
|
|
|
strinfo->element.numbursts++;
|
|
|
|
} else if(strinfo->element.burstsize < mcast_stream_trigger){
|
|
|
|
strinfo->element.burststatus = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
strinfo->element.count++;
|
From Miha Jemec:
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
2006-04-24 19:10:36 +00:00
|
|
|
}
|
|
|
|
|
2014-11-16 15:28:51 +00:00
|
|
|
/*
|
|
|
|
* Editor modelines - http://www.wireshark.org/tools/modelines.html
|
|
|
|
*
|
|
|
|
* Local variables:
|
|
|
|
* c-basic-offset: 4
|
|
|
|
* tab-width: 8
|
|
|
|
* indent-tabs-mode: nil
|
|
|
|
* End:
|
|
|
|
*
|
|
|
|
* vi: set shiftwidth=4 tabstop=8 expandtab:
|
|
|
|
* :indentSize=4:tabSize=8:noTabs=true:
|
|
|
|
*/
|