test sur le multicast
Eric Doutreleau
Eric.Doutreleau at int-evry.fr
Tue Feb 26 17:28:22 CET 2002
sorry i made this resume in french.
Voici un petit resume de la config et des tests effectues.
Nous avons au niveau reseau un commutateur / routeur 6500 Cisco.
Sur ce commutateur nous avons un lien gigabyte vers un cisco 3548.
Sur ce cisco 3548 nous avons deux port 100 Mbit
le serveur vls se trouve sur un port de ce switch 3548 dans le VLAN 50
les clients se trouve sur un autre port de ce switch mais dans deux VLANS
21 et 50.
Ces clients étaient des PC redhat 7.2 avec le vlc 0.2.92
J'ai honteusement pompe dex extraits de 3 DVD.
J'ai d'abord lance le vls non patché avec 3 flux multicast.
le serveur vlcs multicast tournait sur la meme machine.
le switch 3548 broadcast sur tous ces ports ( pas bon ça )
le 6509 se prend 10% de CPU par flux dans le museau ( pas bon ça )
Par contre tout fonctionnait impec au niveau client qui etait configure
avec le channel serveur.
Le changement de chaine prenait environ quelques secondes
Nous avons alors sauvagement patche le code du vls pour que celui
soit envoie une annonce igmp au debut de chaque flux multicast et
quitte le groupe multicast a la fin ( cf grospatch en attachement ; ce
patch contient egalement le patch sur le ttl de bozo ).
La qualite du patch n'est pas terrible terrible. En particulier il manque
un test sur l'adresse de destination. Pour l'instant toutes les adresses
sont considérées multicast.
Cela nous convient parfaitement mais ce n'est pas quelque chose qui peut
être généralisé
On a de plus configure le 6509 en proxy cgmp pour que celui forwarde
les annonces IGMP aux switchs.
Le resultat est donc le suivant:
-Le reseau meme a 3 flux n'est pas tres charge . On a bien du 8Mbit par
flux.
-Le switch 3548 ne broadcaste le flux que sur les ports concernes ( c'est
bien )
-Le routeur commutateur 6509 a sa charge CPU qui baisse tres nettement
par rapport à l'utilisation du vls non patché et qui n'atteint pas les 1%
quand les trois flux sont lancés.
Quand on lance plus de 4 flux cela devient saccadé sur le client.
Mais peut etre cela vient du serveur
En conclusion cela fonctionne assez bien.
Hope that help
--
Eric Doutreleau
I.N.T | Tel : +33 (0) 160764687
9 rue Charles Fourier | Fax : +33 (0) 160764321
91011 Evry France | email : Eric.Doutreleau at int-evry.fr
-- Attached file included as plaintext by Listar --
-- File: grospatch
diff -ur vls-0.3.1/src/modules/netchannel/netchannel.cpp mult/vls-0.3.1/src/modules/netchannel/netchannel.cpp
--- vls-0.3.1/src/modules/netchannel/netchannel.cpp Thu Dec 6 16:32:24 2001
+++ mult/vls-0.3.1/src/modules/netchannel/netchannel.cpp Fri Feb 1 18:19:17 2002
@@ -83,8 +83,12 @@
C_String strDstHost = pApp->GetSetting(m_strName+".DstHost", "239.0.0.3");
C_String strDstPort = pApp->GetSetting(m_strName+".DstPort", "1234");
+ C_String strTTL = pApp->GetSetting(m_strName+".TTL", "0");
+ unsigned char iTTL = strTTL.ToInt();
+
m_pOutput = new C_NetOutput(strInterface,
- strSrcHost, strSrcPort, strDstHost, strDstPort);
+ strSrcHost, strSrcPort, strDstHost, strDstPort,
+ iTTL);
}
diff -ur vls-0.3.1/src/modules/netchannel/netoutput.cpp mult/vls-0.3.1/src/modules/netchannel/netoutput.cpp
--- vls-0.3.1/src/modules/netchannel/netoutput.cpp Thu Dec 6 16:32:24 2001
+++ mult/vls-0.3.1/src/modules/netchannel/netoutput.cpp Mon Feb 4 14:16:53 2002
@@ -39,6 +39,9 @@
#include "netoutput.h"
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
//******************************************************************************
// C_NetOutput class
@@ -51,12 +54,15 @@
//------------------------------------------------------------------------------
C_NetOutput::C_NetOutput(const C_String& strInterface,
const C_String& strSrcHost, const C_String& strSrcPort,
- const C_String& strDstHost, const C_String& strDstPort)
+ const C_String& strDstHost, const C_String& strDstPort,
+ unsigned char iTTL)
: C_Output(TS_IN_ETHER), m_cSocketBuff(TS_IN_ETHER),
m_strInterface(strInterface),
m_strSrcHost(strSrcHost), m_strSrcPort(strSrcPort),
m_strDstHost(strDstHost), m_strDstPort(strDstPort)
{
+ m_iTTL = iTTL;
+
// Init the buffer
for(int iIndex = 0; iIndex < TS_IN_ETHER; iIndex++)
m_cSocketBuff.SetSlotSize(iIndex, TS_PACKET_LEN);
@@ -122,6 +128,22 @@
}
#endif
+ // Set the Time To Live value if != 0
+ if(m_iTTL)
+ m_cSocket.SetOption(IPPROTO_IP, IP_MULTICAST_TTL, &m_iTTL, sizeof(m_iTTL));
+
+
+// if( IN_MULTICAST(inet_addr(m_strDstHost.GetString())))
+// {
+// Ce serait bien d'avoir ici un test sur l'adresse multicast
+// qui fonctionne
+ struct ip_mreq imr;
+ imr.imr_interface.s_addr = INADDR_ANY;
+ imr.imr_multiaddr.s_addr = inet_addr(m_strDstHost.GetString());
+ m_cSocket.SetOption(IPPROTO_IP, IP_ADD_MEMBERSHIP, (char*)&imr, sizeof(struct ip_mreq) );
+ // }
+// fin du test
+
// Bind it to the local address
m_cSocket.Bind(m_strSrcHost, m_strSrcPort);
@@ -144,6 +166,15 @@
{
try
{
+// if( IN_MULTICAST(inet_addr(m_strDstHost.GetString())))
+// {
+// Ce serait bien d'avoir ici un test sur l'adresse multicast
+// qui fonctionne
+ struct ip_mreq imr;
+ imr.imr_interface.s_addr = INADDR_ANY;
+ imr.imr_multiaddr.s_addr = inet_addr(m_strDstHost.GetString());
+ m_cSocket.SetOption(IPPROTO_IP, IP_DROP_MEMBERSHIP, (char*)&imr, sizeof(struct ip_mreq) );
+// }
m_cSocket.Close();
}
catch(E_Exception e)
diff -ur vls-0.3.1/src/modules/netchannel/netoutput.h mult/vls-0.3.1/src/modules/netchannel/netoutput.h
--- vls-0.3.1/src/modules/netchannel/netoutput.h Thu Dec 6 16:32:24 2001
+++ mult/vls-0.3.1/src/modules/netchannel/netoutput.h Fri Feb 1 18:19:17 2002
@@ -43,7 +43,8 @@
public:
C_NetOutput(const C_String& strInterface,
const C_String& strSrcHost, const C_String& strSrcPort,
- const C_String& strDstHost, const C_String& strDstPort);
+ const C_String& strDstHost, const C_String& strDstPort,
+ unsigned char iTTL);
virtual ~C_NetOutput();
virtual void OnInit();
@@ -61,6 +62,8 @@
C_String m_strSrcPort;
C_String m_strDstHost;
C_String m_strDstPort;
+ unsigned char m_iTTL;
+
C_InetAddr m_cOutputInetAddr;
#ifdef BUGGY_VLC
byte m_ByteBuff[TS_PACKET_LEN * TS_IN_ETHER];
--
This is the vls-devel mailing-list, see http://www.videolan.org/vls-devel/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vls-devel
mailing list