Discussion :

[kickflip1408]

Bonjour à tous,
Le socket fonctionne avec une adresse IP locale mais quand j'essaye avec celle distante le socket "s'éteint apparemment car il ne sait plus le lire dans la mémoire:

Je ne comprends pas pourquoi ça ne le fait pas avec une adresse locale.
Merci d'avance.

[imperio]

Il nous manque beaucoup d'information là... Qu'est-ce que tu appelles "à distance" pour commencer ? Réseau local ? PC distant en dehors de ton réseau ? Dans le deuxième cas, si c'est un pc derrière une box, il te faudra ouvrir le port que tu veux binder.

Ensuite, nous montrer un peu de code nous aiderait grandement.

[kickflip1408]

C'est apparemment de cette fonction que vient le problème :
Et je viens d'essayer avec un deuxième ordinateur en utilisant une addresse IP locale (donc 192.168.0.x)

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
 
bool Network::Download(std::string filename, std::string type)
{
	char Exist[16] = "";
	send(sock, "Send", 128, 0);
	send(sock, filename.c_str(), 128, 0);
	send(sock, type.c_str(), 8, 0);
	recv(sock, Exist, 64, 0);
	if (Exist[0] == 'E')
	{
		std::ofstream file;
 
		if (type == "Song")
			file.open("song.mp3", std::ios::binary | std::ios::trunc);
		else if (type == "Text")
			file.open("text.txt", std::ios::binary | std::ios::trunc);
		else if (type == "Image")
			file.open("img.png", std::ios::binary | std::ios::trunc);
		else if (type == "List")
			file.open("list.txt", std::ios::binary | std::ios::trunc);
		else if (type == "Playlist")
			file.open("playlist.txt", std::ios::binary | std::ios::trunc);
 
 
 
		char lenght[64];
 
		recv(sock, lenght, 64, 0); long long int l = atoi(lenght) + 1;
		std::vector<char> v(l);
 
		recv(sock, v.data(), l, 0);
 
		file.write(v.data(), l);
		file.close();
	}
	return true;
}

Et le port utilisé est bien ouvert.

[BufferBob]

salut,

• c'est du C++, on est dans le forum C (NdlM : discussion déplacée)
• c'est quoi sock ? une variable globale ? déclarée et initialisée comment ?

[kickflip1408]

Oui c'est du c++ mais comme le problème viens du socket je me suis dit que le forum c était plus adapté.
Et sock c'est une variable de type SOCKET.

Déclaration :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Network
{
	public:
		Network();
		bool Connect(std::string username, std::string serverip);
		bool Download(std::string filename, std::string type);
		~Network();
		SOCKET sock;
 
	private:
		WSADATA WSAData;
		SOCKADDR_IN sin;
};

Initialisation :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
bool Network::Connect(std::string username, std::string serverip)
{
	WSAStartup(MAKEWORD(2, 2), &WSAData);
	sock = socket(AF_INET, SOCK_STREAM, 0);
	sin.sin_addr.s_addr = inet_addr(serverip.c_str());
	sin.sin_family = AF_INET;
	sin.sin_port = htons(25565);
	connect(sock, (SOCKADDR *)&sin, sizeof(sin));
	send(sock, (username).c_str(), 64, 0);
 
	return true;
}

[BufferBob]

comme le problème viens du socket je me suis dit que le forum c était plus adapté.

je vois pas le rapport

aussi tu notes plus haut que tu test sur 192.168.0.x, ce n'est pas une IP locale à proprement parler, c'est une IP de ton réseau local, mais pour le système c'est bien une IP distante (ça sort de la carte réseau, pas comme 127.0.x.x)
tu es sûr que le serveur en face était bien joignable (chemin ok + port ouvert, => netcat ?) ?

sinon ne causant pas C++ pour deux sous je pourrai pas t'aider plus pour ma part dsl

[kickflip1408]

Oui, les deux ordinateurs sont connectés car mon serveur lui envoie bien des fichiers mais après plusieurs envois (2-3 fichiers), le socket se déconnecte, je pense. Et j'ai vérifié les fichiers reçus qui était correctement reçus (identique au fichier source). Mais je ne sais pas pourquoi car quand je fais serveur + client sur le même ordinateur tout se passe bien.

[Bktero]

Bonjour,

Je déplace la discussion dans le forum C++.

[Bousk]

On va se répéter mais bon...
ton code est loin d'être bon, tes symptomes n'ont aucun sens et ton "problème" ne veut rien dire.
Un socket TCP ne se ferme pas tout seul par magie, s'il se ferme c'est qu'un des 2 côtés le ferme, ou que le réseau est mort (cable arraché, ..). Tu peux toujours essayer de choper l'erreur aussi.
Tu utilises surtout des buffers au petit bonheur la chance et dois avoir bien de la chance que ça marche ne serait-ce qu'une fois. Parce que faire un send(sock, "Send", 128, 0); c'est plutôt périlleux.

[kickflip1408]

Pourquoi est-ce périlleux ? (Je suis débutant donc tout conseil est le bienvenu)
Et j'ai trouvé l'erreur le programme se coupe car "libpng error bad adaptive filter value".
Donc c'est le fichier reçu qui est modifié mais seulement les .png, les .txt sont identiques aux fichiers sources.
Mais ce que je n'arrive pas à comprendre c'est pourquoi quand je le fait sur un seul ordinateur ça fonctionne alors qu'avec deux ça me fait cette erreur.

[fenkys]

Bonjour,

Déjà tu peux te reporter à la discussion que tu as ouvert sur le même sujet, lire mes commentaires et en tenir compte, en particulier les points 2 et 3. Une fois que tu auras fait tout ça, tu pourras redemander de l'aide.

Cordialement.

[Bousk]

Pourquoi est-ce périlleux ? (Je suis débutant donc tout conseil est le bienvenu)

Un conseil ? Lis la doc
Quand c'est précisé sur tout internet que le 3° paramètre est la longueur du buffer passé en 2° paramètre, et que tu mets un 128 pour une chaîne de.. 4 caractères...
Non vraiment, rien ne te choque ?

Et j'ai trouvé l'erreur le programme se coupe car "libpng error bad adaptive filter value".
Donc c'est le fichier reçu qui est modifié mais seulement les .png, les .txt sont identiques aux fichiers sources.
Mais ce que je n'arrive pas à comprendre c'est pourquoi quand je le fait sur un seul ordinateur ça fonctionne alors qu'avec deux ça me fait cette erreur.

Si le problème vient de la libpng, sur un même ordinateur tu utilises.. la même lib. Ton ordinateur distant pas forcément.

http://lmgtfy.com/?q=socket+C+send

[kickflip1408]

Ok merci je modifierais ça mais en farfouillant un peu avec Notepad ++, j'ai remarqué que toute une partie du fichier était manquante et les caractères manquants étaient remplacés par des "void". Donc ce n'est pas vraiment libpng ce sont bien les sockets le problèmes donc j'ai aussi vérifié si c'était dû à la lecture du fichier sur le serveur (on ne sait jamais) mais là tout le fichier y était. Donc ça ne peut-être que les sockets. J'ai donc essayé d'envoyer le fichier en de plus petits paquets (plus de bugs en-dessous de 128 octets par paquet). Ce qui est étonnant c'est que je n'ai besoin de faire ça qu'avec l'IP "distante" (sur le même ordinateur)
ou avec deux ordinateurs différents. Le TCP ne garantit-il pas l'intégralité des données envoyées ?
Edit : Fenkys, je ne l'avait pas vu excuse moi, j'avais cru avoir résolu ce problème là en ayant celui-ci qui finalement est encore le même problème.

[bacelar]

Le TCP ne garantit-il pas l'intégralité des données envoyées

A que non !
Il garantie que les données seront reçu en séquence, si elles sont reçues.
Il ne garantie pas non plus que l'envoie d'une série d'octet sera reçu en un coup de l'autre coté.
Lisez cette foutue documentation.

[BufferBob]

Le TCP ne garantit-il pas l'intégralité des données envoyées ?

A que non !

enfin, sans garantir l'intégrité il effectue quand même une somme de contrôle, en pratique perdre des paquets UDP est assez rare, mais tomber sur des paquets TCP "endommagés" et ayant un checksum valide qui passent le driver et remontent endommagés à l'application doit être encore plus bien plus rare

je plussoie le fait de lire la doc cela dit

[bacelar]

TCP ne garantit pas la bonne réception des données, somme de contrôle ou pas.
Quand vous utilisez une socket TCP en émission, au retour de l'envoie, la seule garantie, c'est que le Kernel a bien enregistré les données à transmettre et qu'il va essayer de les transmettre, pas plus de garanties que ça.

[kickflip1408]

Merci pour vos conseils je vais lire la doc' et refaire mon programme plus proprement avec ce que vous m'avez dit.

[Bousk]

TCP garantit que les données envoyées seront reçues, et dans l'ordre. Tant que la connexion est maintenue, des deux côtés, "assez longtemps pour tout transférer".
Il reste que si tu veux t'assurer que les données ont vraiment été reçues, le destinataire doit t'envoyer un ack. Tu ne peux pas ouvrir la boîte noire TCP pour vérifier le ack utilisé en interne pour t'en assurer. Il faut passer par un ack applicatif.

en pratique perdre des paquets UDP est assez rare

On estime cette perte à <5% en temps normal. C'est loin d'être rare en pratique, vu qu'on utilisera UDP pour faire du P2P, souvent du hole punching, où on l'envoit ~10-100 packet/s, ça fait déjà une poignée de paquets perdus par seconde.

[bacelar]

TCP garantit que les données envoyées seront reçues, et dans l'ordre. Tant que la connexion est maintenue, des deux côtés, "assez longtemps pour tout transférer".

Ça garantie donc que dalle. On n'ai donc d'accord. Surtout avec l'algorithme Nagle activé.
https://fr.wikipedia.org/wiki/Algorithme_de_Nagle
Merci pour vos pouces rouges, ça fait toujours plaisir.

Comme l'indique @Bousk, il vous faut un acquittement applicatif pour garantir une bonne réception des données par l'application distance. (niveau 5 "session" du modèle OSI de l'ISO).

[Médinoc]

Avec les garanties de TCP citées par Bousk, ça veut au moins dire qu'un seul acquittement applicatif suffit, à la fin du transfert; pas besoin de gymnastique bizarre de correction d'erreurs avancée, à moins de données vraiment sensibles.