Discussion :

[kickflip1408]

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.

[Invité]

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?

[supersnail]

Bonjour,

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

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

[kickflip1408]

Le code pour l'envoi :

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
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 :

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
 
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;
}

[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
_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 :

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

1
2
for (int j = 0; j < speed; j++)
			file.get(c[j]);

t'aimes bien les boucles et faire compliqué non ?

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..
C'est même très mauvais en fait.
Et Sleep(1); à la réception, sur chaque octet , 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.

[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 ?

[Bousk]

Non un VLA ce serait char c[speed]; où speed n'est pas une constante connue à la compilation.

[bacelar]

J'ai ripé sur le Ctrl-C + Ctrl-V.

[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 :

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

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);
    }

[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.

[prgasp77]

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.

Quitte à découper un gros bloc de 12Go en plusieurs morceaux.

[fenkys]

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.

[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.