Perte de données avec sockets

Version imprimable

01/11/2015, 12h18
kickflip1408

Perte de données avec sockets

Bonjour à tous,

J'aimerais envoyer des fichiers avec les sockets en TCP, quand je me connecte en local tout va bien aucune perte quelle que soit la taille du packet envoyé mais dès que ce n'est plus en local je dois envoyer mon fichier par packet de 1 (Ce qui n'est pas très rapide).

Alors je voulais savoir si il y a moyen de ne pas avoir ces pertes tout en gardant de bonnes performances.

Merci d'avance.
01/11/2015, 12h47
Invité

TCP des pertes?

A ce que je sache il n'y a pas de perte de donnée avec TCP.
Est ce que la perte de donnée n'est pas liée a ton code?
01/11/2015, 12h54
supersnail

Bonjour,

Comme le dit Ratator, le problème viendrait plus de ton code que de TCP ? :koi:

Pourrais-tu nous montrer le-dit code du coup ?

Le code pour l'envoi :

Code:

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
43
44
45
46
 
bool Client::SendFile(int speed)
{
	char filename[128] = "";
	while (filename[0] != 'M')
	{
		recv(socket, filename, 128, 0);
 
	}cout << filename << endl;
	cout << filename << endl;
	ifstream file(filename, ios::binary);
	long long int s;
 
	if (file)
	{
		file.seekg(-1, ios_base::end);
		s = file.tellg();
	}
	file.seekg(0, ios::beg);
 
	char buffer[16], buf[1];
	_itoa(s, buffer, 10);
 
	send(socket, buffer, 128, 0);
	cout << buffer << endl;
 
	char *c = new char[speed];
	file.seekg(0, ios::beg);
	int i;
	for (i = 0; i < s / speed; i++)
	{
		for (int j = 0; j < speed; j++)
			file.get(c[j]);
		send(socket, c, speed, 0);
	}
	if (s > i * speed)
	{
		for (int j = 0; j < s - i * speed; j++)
			file.get(c[j]);
		send(socket, c, s - i * speed, 0);
	}
	cout << "Sended" << endl;
 
	file.close();
	return true;
}

Pour la réception :

Code:

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
 
bool Network::Download(std::string filename, string type)
{
	send(sock, filename.c_str(), 128, 0);
	if (type == "Song")
	{
 
		char buf[128], c[SPEED];
 
		std::ofstream file("song.mp3", std::ios::binary);
		recv(sock, buf, 128, 0);
		int i, k;
		for (i = 0; i < atoi(buf) / SPEED; i++)
		{
			recv(sock, c, SPEED, 0);
			for (int j = 0; j < SPEED; j++)
				file << c[j];
			Sleep(1);
		}
		if (atoi(buf) > i * SPEED)
		{
			recv(sock, c, atoi(buf) - i * SPEED, 0);
			for (int j = 0; j < atoi(buf) - i * SPEED; j++)
				file << c[j];
			Sleep(1);
		}
		file.close();
	}
	return true;
}

02/11/2015, 10h33
Bousk
Il n'y a aucune perte en TCP tant que tu n'es pas déconnecté

Ton sendFile commence par faire un recv !? déjà c'est bizarre :weird:
_itoa on a connu mieux mais ok
for (i = 0; i < s / speed; i++) t'es sur de toi là ? et à quoi sert ce "speed" ?
Code:

1 2 for (int j = 0; j < speed; j++) file.get(c[j]);
t'aimes bien les boucles et faire compliqué non ? :roll:

Citation:

dès que ce n'est plus en local je dois envoyer mon fichier par packet de 1 (Ce qui n'est pas très rapide).

C'est ton code qui envoit par paquet de 1 et ce n'est pas du tout obligatoire non.. :weird:
C'est même très mauvais en fait.
Et Sleep(1); à la réception, sur chaque octet 8O, n'aide sûrement pas à ta vitesse..

T'es en TCP, y'a rien de plus simple, tu lis ton fichier en 1 fois dans 1 buffer et le balance. Eventuellement tu envois un premier buffer pour préciser sa taille comme tu le fais déjà. Mais c'est tout. Tout le découpage du fichiers en buffers et l'envoi/réception est géré par TCP. Toi tu send, recv et basta.
02/11/2015, 13h17
kickflip1408

Merci pour ta réponse mais je ne vois pas comment lire le fichier en un coup, y a-t-il une fonction toute faite pour le faire ?
02/11/2015, 16h10
Bousk

Non un VLA ce serait char c[speed]; où speed n'est pas une constante connue à la compilation.
03/11/2015, 11h36
bacelar

J'ai ripé sur le Ctrl-C + Ctrl-V. :aie:
05/11/2015, 10h33
fenkys
Bonjour,

Si j'ai pigé ton algorithme, tu envoies d'abord la longueur des donneés puis les données elles-mêmes.
Coté reception, tu lit cette longueur et tu initialise le buffer.

1) Comment le atoi sait il ou trouver la fin de la longueur. Tu n'as mis aucun séparateur. Si ta longueur est suivie d'un octet du style 0x30 a 0x39, tu vas avoir un problème. Et c'est du binaire, tu peux recevoir absolument n'importe quoi, y comris des valeurs pouvant être interprétés comme des chiffres.

2) Tu rejetes les données qui ont été acquises dans ton buffer en même temps que cette longueur. Les interfaces socket sont des flux. Ce n'est pas parce que tu fais deux send, que tu auras deux recv côté réception. Tes deux send peuvent très bien être intégrés en une seule trame réseau. Ton recv recevant jusqu'à 128 octets, il y a même de fortes chances que tu recoives d'autres données.

3) Tu ne vérifie pas la longueur des données lues. Tu considère qu'à chaque fois tu reçois "speed" caractères. Ce n'est pas forcement vrai. Voici un code (ecrit à l'arrache, pas vérifié) qui fait ce que tu cherches de façon plus fiable (mais pas sécurisée) et remplace tes deux boucles successives :
Code:

1 2 3 4 5 6 7 ssize_t readSz; for( ssize_t totalSz = 0; totalSz < atoi(buf); totalSz += readSz ) { readSz = recv(sock, c, SPEED, 0); file.write(c,readSz); }
06/11/2015, 12h15
Médinoc

Franchement, une donnée qui indique la longueur des données qui suivent, c'est un peu une mauvaise idée qu'elle soit elle-même à longueur variable. Personnellement je l'aurais envoyée en binaire (32 ou 64 bits selon qu'on veuille supporter des tailles supérieures à 2/4GiO) plutôt qu'en texte.
06/11/2015, 14h02
prgasp77

Citation:

Envoyé par Médinoc

Franchement, une donnée qui indique la longueur des données qui suivent, c'est un peu une mauvaise idée qu'elle soit elle-même à longueur variable. Personnellement je l'aurais envoyée en binaire (32 ou 64 bits selon qu'on veuille supporter des tailles supérieures à 2/4GiO) plutôt qu'en texte.

:plusser:
Quitte à découper un gros bloc de 12Go en plusieurs morceaux.
09/11/2015, 09h48
fenkys

Citation:

Envoyé par Médinoc

Franchement, une donnée qui indique la longueur des données qui suivent, c'est un peu une mauvaise idée qu'elle soit elle-même à longueur variable. Personnellement je l'aurais envoyée en binaire (32 ou 64 bits selon qu'on veuille supporter des tailles supérieures à 2/4GiO) plutôt qu'en texte.

Tu serais surpris du nombre d'appareils qui fonctionnent comme cela dans la vraie vie.
09/11/2015, 10h11
Médinoc

Je sais, et je sais que divers protocoles "text-based" comme HTTP ou FTP fonctionnent comme ça... et je sais aussi que c'est PITA à implémenter.