Discussion :

[Pasqualini]

Bonjour,
pour connaitre les octets reçus ou envoyés, j'utilise le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
void TDebits::RecusEnvoyes(unsigned long int& Recus, unsigned long int& Envoyes)
{
	char buf[256];
	unsigned int uiRecus, uiEnvoyes;
	HINSTANCE Dll =LoadLibrary(L"iphlpapi.dll");
	if(Dll == NULL)
	{
		AnsiString asLigne = "Impossible de charger la DLL iphlpapi.dll";
		asLigne += "\n Le programme va se fermer";
		ShowMessage(asLigne);
		Close();
	}
 
	PMIB_IFTABLE buffer;
	MIB_IFROW donnees;
	DWORD getiftable_rc;
	ULONG buf_size = 0;
	typedef DWORD( *MYDLLFUNCTION)( PMIB_IFTABLE , PULONG , BOOL );
 
	MYDLLFUNCTION getiftable;
 
	getiftable = (MYDLLFUNCTION)GetProcAddress(Dll, "GetIfTable");
	buffer = (MIB_IFTABLE*) malloc(sizeof(MIB_IFTABLE));
	getiftable_rc = getiftable(buffer, &buf_size, TRUE);
	free(buffer);
	buffer = (MIB_IFTABLE*) malloc(buf_size);
	getiftable_rc = getiftable(buffer, &buf_size, TRUE);
	DWORD dwOutOctets, dwInOctets;
	dwOutOctets = dwInOctets =0;
 
	for(unsigned int i = 0; i < buffer->dwNumEntries; i++)
	{
		donnees = buffer->table[i];
		dwOutOctets  += donnees.dwOutOctets;
		dwInOctets  += donnees.dwInOctets;
	}
	uiRecus =  dwInOctets;
	uiEnvoyes = dwOutOctets;
	Recus = uiRecus;
	Envoyes = uiEnvoyes;
}
//---------------------------------------------------------------------

Cela semble fonctionner correctement la plupart du temps. De temps en temps, j'ai des informations notablement fantaisistes, tel qu'un débit obtenu par la différence entre 2 quantités d'octets reçus divisée par la différence de temps en secondes entre les 2 valeurs. J'obtiens, par exemple, 4 MOctets/s, valeur en désaccord avec d'autres logiciels de mesure de débits.

Quelqu'un aurait-il une idée sur ce problème ?

Merci d'avance.

[ShaiLeTroll]

Où est la mesure de temps ?
Si tu utilises cette fonction pour un "snapshop" des données échangées
GetIfTable donne-t-elle des données globales à l'OS, donc je suppose que tu envoie toi même une trame d'une donnée définie ?
Pense qu'un autre processus peut prendre la main à tout moment, et donc faussé le temps d’exécution entre deux "snapshop", donc l'allonger !

Si tu arrêtes ta mesure de temps puis que tu appelles ta fonction RecusEnvoyes, un autre thread peut prendre à ce moment, il peut lui-même utiliser un Socket, il peut donc ajouter des données avant ton "snapshot", du coup tu augmentes faussement le débit !

Que fourni MIB_IFROW.dwSpeed ? une vitesse théorique ?

Compare avec la FAQ : Comment puis-je connaître la vitesse de téléchargement avec un TidHTTP ?

Regarde les sources fournis de ouiouioui avec le sujet Tester sa connexion ADSL (bande passante)

Ainsi que les sources ICI


Voir aussi le Ping (ICMP) comme dans ce code de la MSDN IcmpSendEcho et sa version Delphi
Pense qu'il y a un délai entre la demande de connexion et la connexion effective, cela peut fausser aussi tes mesures de temps !

[Pasqualini]

Merci pour cette réponse.

La procédure est appelée par un TTimer toutes les secondes.
Les données reçues sont stockées dans un vecteur. Chaque élément du vecteur contient les 2 données et la date à laquelle ces 2 données ont étrté recueillies. La date est obtenue par Now(). La valeur du débit est obtenue en prenant les octets reçus entre 2 dates et en divisant leur différence par la différence des dates.

Je ne connais pas les Indy. Je fais surtout du calcul scientifique.
Mais la solution est probablement dans l'utilisation de composant Indy.

Je vais chercher.

[ShaiLeTroll]

Un Timer, ce n'est pas très précis !
Suffit que ton programme fasse autre chose et cela peut différer la gestion du WM_TIMER, tu pourras avoir des intervalles assez variables !
Tout dépend de l'activité en cours, qui émets les données de tests, un thread parallèle ? il faut qu'il dure au moins le temps entre deux relevés !

Oui, ton système de mesure doit être perturbé par d'autre éléments, surtout qu'entre le Now() et le GetIfTable, tu as peut-être un certain nombre de fonction, à tout moment, ton thread peut perdre la main !
Au final, tu mesures plus l'activité du poste que le débit !

[Pasqualini]

La date est prise au retour de la procédure.
Les intervalles ne peuvent pas être très variables autour de la seconde.
Je pense que l’erreur doit venir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
for(unsigned int i = 0; i < buffer->dwNumEntries; i++)
	{
		donnees = buffer->table[i];
		dwOutOctets  += donnees.dwOutOctets;
		dwInOctets  += donnees.dwInOctets;
	}

Lorsque j'ai fait des mesures de débit, l'ordinateur ne faisait pratiquement que cela.

[Pasqualini]

J'ai résolu mon problème.
La solution est plutôt…bizarre !

Le problème venait de la DLL iphlpapi.dll incluse dans Windows 7.
J'avais récupéré sur Internet une autre iphlpapi.dll avec laquelle je n'avais pas ce problème. J'en avais un autre : je ne pouvais pas récupérer l'adresse IP Externe.

Ma solution a été d'utiliser la DLL que j'avais récupérée sur Internet et de la renommer pour récupérer les quantités d'octets reçus ou envoyés et d'utiliser la DLL fournie par Windows 7 pour récupérer l'adresse IP externe.

Je vais quand même étudier la proposition de ShaiLeTrol d'utiliser les composants Indy.

[ShaiLeTroll]

Est-ce un Windows Seven 64Bits ?
Si oui, il y a peut-être une séparation entre 32Bits et 64Bits !
La DLL iphlpapi.dll de Seven est en fait celle de WOW pour les programmes 32Bits et les données ne concernent peut-être que les flux réseaux des programmes 32Bits ?

Tu devrais comparer avec le moniteur de performances intégrés à Windows, si il existe toujours, voir les chiffres qu'ils donnent par rapport aux autres logiciels !

[Pasqualini]

Je travaille, actuellement, avec Windows 7, 32 bits.

Je ne connais pas assez l'analyseur de performances pour en tirer quelque chose.