Problème socket en distant

Version imprimable

06/11/2015, 11h32
kickflip1408

1 pièce(s) jointe(s)

Problème socket en distant

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:
Pièce jointe 191992
Je ne comprends pas pourquoi ça ne le fait pas avec une adresse locale.
Merci d'avance.
06/11/2015, 11h38
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.

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:

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.

06/11/2015, 12h56
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 ?

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:

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:

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

06/11/2015, 13h17
BufferBob

Citation:

Envoyé par kickflip1408

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

je vois pas le rapport :koi:

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
06/11/2015, 13h26
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.
06/11/2015, 13h54
Bktero

Bonjour,

Je déplace la discussion dans le forum C++.
06/11/2015, 18h03
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. :weird:
06/11/2015, 18h47
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.
09/11/2015, 09h59
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.
09/11/2015, 11h32
Bousk

Citation:

Envoyé par kickflip1408

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

Un conseil ? Lis la doc :weird:
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 ? :weird:

Citation:

Envoyé par kickflip1408

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

http://lmgtfy.com/?q=socket+C+send
09/11/2015, 19h10
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.
09/11/2015, 23h46
bacelar

Citation:

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.
10/11/2015, 00h44
BufferBob

Citation:

Envoyé par bacelar

Citation:

Envoyé par kickflip1408

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
10/11/2015, 03h29
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.
10/11/2015, 07h39
kickflip1408

Merci pour vos conseils je vais lire la doc' et refaire mon programme plus proprement avec ce que vous m'avez dit.
10/11/2015, 10h05
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.

Citation:

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.
10/11/2015, 16h26
bacelar

Citation:

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

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).
10/11/2015, 16h42
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.
10/11/2015, 17h59
bacelar

@Bousk, @Médinoc, vous savez très bien que les débutants mettent à la trappe le "assez longtemps pour tout transférer".
Et les cours de réseaux aussi, c'est pas vraiment la faute des débutants.
Et vous savez aussi que pour implémenter correctement un protocole applicatif, il faut être conscient que TCP ne garantit pas la bonne réception des données.

Citation:

ç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

Je n'en disconviens pas, bien au contraire, il s'agit bien d'un simple acquittement applicatif, mais il ne se fera pas tout seul. ;)