slides - Tounkan`s home page

PROJET RES
Module de M1 de la mention Informatique
Spécialité Réseaux, 2e semestre 2004­2005
Université Pierre et Marie Curie
>> Présentation du projet <<
Conception et réalisation d'un Proxy Realplayer et test de ses performances dans un réseau WiFi
présentation composée et présentée par
Danjon Florent
Diallo Alpha Amadou Tounkan Khaled Noui Ribeiro Alexandre Plan
1
Introduction
2
Objectifs
3
Etude de l'existant
4
Authentification
5 Optimisation de la bande passante
36
Passage à IPv6
7
Conclusion
Introduction:
Objectif: développement d’un proxy real player à mettre en place dans le cadre du réseau infradio.
Problématique: Implémenter l'existant pour y ajouter un processus d’authentification, optimiser la bande passante et le faire fonctionner avec IPv6.
Le RTSP proxy kit de RealNetwork:
Le répertoire rtspproxy contient les classes principales du proxy:
­Le thread principal recevant les messages.
­Les classes traitant ces messages.
­Les classes contenant les couples de connexions: client<­­>proxy<­­>serveur.
Architecure:
CServerCnx
CClientCnx
CRtspProxyCnx
CRtspProxyApp
CRtspSession
CRtspDataTunnel
L'unique thread recevant les messages: CRtspProxyApp.
Contrôle les activitées du cache.
Par un booléen.
Possède une liste d ’objets CRtspProxyCnx.
Ces objets gèrent messages reçu par le proxy.
Un objet CRtspProxyCnx est ajouté pour chaque nouveau client.
Classes traitant les messages: CRtspProxyCnx, CClientCnx et CServerCnx.
Ces classes ont comme principales fonctions de créer des réponses et des requêtes à partir des messages reçus.
Chacune des classes représente une partie de la communication:
le client, le proxy et le serveur.
Ces classes assurent le fonctionnement du protocole.
Les informations connectant client et serveur:
Celles ci sont contenues dans la classe CRtspProxySession:
­Segment de cache
­Serveur et Client ID
­Liste de CRtspProxyDataTunnel.
­4 ports (proxyclient, proxyserveur, client, serveur).
­Adresses (client et serveur)
Une liste de session se trouve rattaché à chaque CrtspProxyCnx.
Le mécanisme d'authentification
• RTSP utilise les mêmes mécanismes d'authentification que HTTP : Basic, Digest
• Le proxy répond à une requête du client par une demande d’authentification
• Le client réitère sa demande en fournissant son identifiant et son mot de passe codés en base64
• Exemple :
etudiant:motdepasse  ZXR1ZGlhbnQ6bW90ZGVwYXNzZQ== Schéma général
client
proxy
serveur
requête
tification
n
e
h
t
u
a
’
d
demande
requête + login
et MDP
fication
ti
n
e
th
u
a
’
demande d
requête + login
et MDP
…
client authentifié ?
requête
réponse
…
­ arrivée de la requête
oui
Processus d’authentification
authentifié
non
déjà venu
oui
non
login + MDP vides
oui
non
­ décoder login + MDP
non
login + MDP correct ?
oui
­ envoyer la requête d’authentification,
­ déjà venu=1
­ retourner authentifié
­ authentifié = 1
­ enregistrer l’accès dans le fichier log
Requête du client
DESCRIBE rtsp://192.168.0.4:554/secure/test.rm RTSP/1.0
CSeq: 2
User­Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (win32)
Accept: application/sdp
Session: 15062­1
Bandwidth: 10485800
ClientID: WinNT_5.1_6.0.12.1056_RealPlayer_R30FRD_fr_686
GUID: 00000000­0000­0000­0000­000000000000
Language: fr, fr, *
RegionData: 0
Require: com.real.retain­entity­for­setup
SupportsMaximumASMBandwidth: 1
Réponse du serveur
RTSP/1.0 401 Unauthorized
CSeq: 2
Date: Wed, 23 Mar 2005 22:07:30 GMT
WWW­Authenticate: Basic realm=" Jussieu.ContentRealm"
Nouvelle requête du client
DESCRIBE rtsp://192.168.0.4:554/secure/test.rm RTSP/1.0
CSeq: 3
User­Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (win32)
Accept: application/sdp
Session: 15062­1
Authorization: Basic ZXR1ZGlhbnQ6bW90ZGVwYXNzZQ==
Bandwidth: 10485800
ClientID: WinNT_5.1_6.0.12.1056_RealPlayer_R30FRD_fr_686
GUID: 00000000­0000­0000­0000­000000000000
Language: fr, fr, *
RegionData: 0
Require: com.real.retain­entity­for­setup
SupportsMaximumASMBandwidth: 1 Exemple
Optimisation
EQUEST:
• Première solution envisagée
SET_PARAMETER rtsp://a1234.l663344176.c6633.e.lr.aka
maistream.net:554/live/D/1234/6633/6
66/reflector:44176 RTSP/1.0
CSeq: 7
SetDeliveryBandwidth: Bandwidth=22119;BackOff=0
Liste des clients
Session: 2049595923­3
Via: RTSP/1.0 293cb936
RESPONSE:
Problème: Réponses du serveur varient suivant les requêtes
RTSP/1.0 200 OK
CSeq: 7
Date: Tue, 21 Jun 2005 11:39:09 GMT
Session: 2049595923­30
Via: RTSP/1.0 293cb936
Optimisation
• Deuxième solution
Liste des réponses
Problème: Réponses aux requêtes varient
suivant les paramètres des clients
Optimisation
• Troisième solution
Problème: Conception du proxy ( diapo suivante)
•Architecture actuelle
CServerCnx
CClientCnx
CRtspProxyCnx
CRtspProxyApp
–
CRtspSession
Solution possible
CRtspProxyCnx
CRtspProxyApp
CRtspSession
Passage d'IPv4 à IPv6
• InfRadio • Pourquoi IPv6?
– Une solution pour les problèmes de croissance
• épuisement des adresses IP
• explosion de la taille des tables de routage
• Les caractéristiques d’IPv6
– Adresse plus longue : 128 bits (16 octets)
– 3 types d'adresses : Unicast/Anycast/Multicast
– Taille fixe de l'en-tête: 40 octets
• Les nouvelles fonctionnalités d’IPv6
– Autoconfiguration/Multicast/Sécurité/Mobilité
Passage d'IPv4 à IPv6
• L'API socket IPv6:
– programmes peuvent fonctionner autant en IPv4 qu'en IPv6 sans recompilation.
– pas spécifique à 1 OS.
• Modifications effectuées:
– fonctions du noyau de l'API socket.
– structures de données dédiées à l'adressage.
– fonctions de conversion des noms vers les adresses.
– fonctions de formatage des adresses.
Passage d'IPv4 à IPv6
Etape1: Fonctions du noyau de l'API socket.
•
Changement des noms des fonctions/variables/macros
•
•
Recherche de
Remplacer par
AF_INET
AF_INET6
PF_INET
PF_INET6
INADDDR_ANY
in6addr_any
IPPROTO_IP
IPPROTO_IPV6
•
Création d’une socket
•
s= socket(PF_INET, SOCK_STREAM, 0) ;
•
s= socket(PF_INET6, SOCK_STREAM, 0) ;
•
s=socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
•
s=socket(PF_INET6, SOCK_DGRAM, IPPROTO_IPV6); //IPv6/UDP
//pour 1 socket IPv4/TCP
//pour 1 socket Ipv6/TCP
// IPv4/UDP
Passage d'IPv4 à IPv6
Etape2: Structures de données dédiées à l'adressage
Structure IPv4 Structure IPv6
struct in_addr{
unsigned int s_addr;
};
struct in6_addr{
uint8_t s6_addr [16]; /*IPv6 address*/
};
struct sockaddr
struct sockaddr_in6
struct sockaddr_in{
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
struct sockaddr_in6{
sa_family_t sin6_family; /*AF_INET6*/
int_port_t sin6_port;
uint32_t sin6_flowinfo; /* IPv6 flow label */
struct in6_addr sin6_addr; /* IPv6 address*/
uint32_t sin6_scope_id; };
};
Passage d'IPv4 à IPv6
Etape3: Fonctions de conversion des noms vers les adresses.
•
Fonction de résolution de nom: gethostbyname()
– Subsiste
– La structure hostent reste inchangée
Struct hostent *gethostbyname(const char*name) ;
•
Nouvelle fonction: gethostbyname2()
– Prise en compte des anciennes et nouvelles adresses.
Struct hostent *gethostbyname2(const char *name, int af);
•
La fonction gethostbyaddr()
– inchangée
•
struct hostent *gethostbyaddr(const char *addr, int len, int type);
Passage d'IPv4 à IPv6
Etape4: Fonctions de formatage des adresses.
•
Conversion des adresses entre les formes binaires et texte imprimable.
•
in_addr_t inet_aton(const char *cp);
•
devient
•
int inet_pton (int af, const char *src, void *dst)
•
char *inet_ntoa(struct in_addr in);
•
devient
•
const char *inet_ntop(int af, const void *src, char *dst, size_t size)
Conclusion
•
Difficultés
– Utilisation du code d'autrui
– Code non documenté
•
– Architecture complexe
Enseignements tirés
– Prévision difficile
– Compréhension du code
– Aptitude à mettre en place une architecture complète d'un projet en C++
•
– Transition en IPv6 non complexe
Perspectives
– Authentification digest
– Architecture plus sophistiquée pour optimisation
– HTTP
•
– IPv4/IPv6
http://pres.ibreizh.com