Fonction WSARecvFrom fail..

Version imprimable

Bonjour,

Je développe un serveur UDP en utilisant les fonctions WSA* de la lib winsock.

Après avoir créer la socket (WSASocket) et la binder comme il faut, je suis face à un problème concernant la fonction WSARecvFrom, voici son implémentation :
Code:

1 2 3 4 5 6 7 8 9 10 11 WSARecvFrom( sock_, &dataBuff, 1, &bytesRecv, &flags, (SOCKADDR *)&senderAddr, &senderAddrSize, &overLapped, NULL );
Le problème vient de la valeur de retour, j'obtiens constamment le code erreur WSAENOBUFS (10055) :
Code:

1 2 No buffer space available. An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.
Or, je pense avoir bien déclaré le buffer de réception (dataBuff) :
Code:

1 2 3 4 5 6 WSABUF dataBuff; const int buffLen = DATA_SIZE; char buff[DATA_SIZE]; dataBuff.len = buffLen; dataBuff.buf = buff;
J'ai lu quelque part que cette erreur apparaissait si le port bindé dépassé la valeur 5000 mais j'utilise le port 1234 et même résultat...

Merci pour votre patience et de l'aide que vous pourrez m'apporter.

13/12/2011, 14h04
niglo

Hello,

ce que je comprends de ton message d'erreur, c'est que ton buffer n'est pas assez grand pour recevoir les données.

Que vaut DATA_SIZE ?

++
14/12/2011, 13h17
ouhare

DATA_SIZE est une macro perso, elle vaut 1024, mais la fonction plante avant même une quelconque réception de données...
14/12/2011, 13h43
niglo

d'après la MSDN, le problème vient du numéro de port de ton socket :
http://support.microsoft.com/kb/196271/fr

Comment sont déclarés senderAddr et sock_ ?
14/12/2011, 13h55
koala01

Salut,

Une petite info au passage : la bibliothèque winsock n'est pas portable (c'est une bibliothèque "made by microsoft" ) :P

Tu me diras sans doute que tu n'en as rien à foutre, mais il se fait qu'il existe une excellente bibliothèque qui permet de gérer les socket (TCP et UDP) de manière transparente et portable pour l'utilisateur, et ce, quel que soit le système pour lequel l'application sera compilée.

Ce n'est pas le moindre intérêt de cette bibliothèque, car elle rend la gestion et l'utilisation des sockets, ports et autres protocoles liés à la transmission des données par le net bien plus faciles ;). j'ai nommé boost asio !

Alors, oui, je sais... Tu vas me rétorquer que l'utilisation de cette bibliothèque te fait penser au fait d'utiliser un bazooka pour tuer une mouche, que tu n'as pas envie d'installer tout boost "uniquement" pour cela, ou encore me trouver plein d'autres faux prétextes pour ne pas suivre ce conseil.

Et pourtant, je peux t'assurer que tu gagnera énormément tant en terme de facilité d'utilisation, qu'en terme de temps de développement ou qu'en terme de portabilité, et qu'il serait donc vraiment dommage de s'en priver ;)
14/12/2011, 15h55
ouhare
Citation:

Envoyé par niglo

d'après la MSDN, le problème vient du numéro de port de ton socket :
http://support.microsoft.com/kb/196271/fr

Comment sont déclarés senderAddr et sock_ ?

Je ne pense pas que cela vienne du numéro de port (j'ai testé avec beaucoup de valeurs différentes),
sinon pour les déclarations :
Code:

1 2 struct sockaddr_in senderAddr; SOCKET sock_;
pour répondre a koala1 :
on m'impose l'utilisation des fonctions WSA* ! je n'ai pas le choix :P

La question de portabilité n'est pas un problème, le tout est abstrait et encapsulé. Je jongle entre deux objets version WIN32 et UNIX (avec les macros #ifdef #endif); du coup mon serveur est utilisable sous Windows et Unix.
Au passage, ma version UNIX fonctionne parfaitement...
14/12/2011, 16h02
koala01

Citation:

Envoyé par ouhare

pour répondre a koala1 :
on m'impose l'utilisation des fonctions WSA* ! je n'ai pas le choix :P

La question de portabilité n'est pas un problème, le tout est abstrait et encapsulé. Je jongle entre deux objets version WIN32 et UNIX (avec les macros #ifdef #endif); du coup mon serveur est utilisable sous Windows et Unix.
Au passage, ma version UNIX fonctionne parfaitement...

Mea culpa... j'ai oublié de préciser : c'est exactement ce que fait boost asio, en t'évitant de devoir réinventer la roue ;)

Maintenant, si c'est pour un TP... Mais penses à asio le jour où tu seras dans une situation similaire à titre privé (ou professionnel) ;)

Peux-tu également montrer comment tu renseignes sock_ et senderAddr ?

Sinon, plusieurs choses à vérifier :

Winsock correctement initialisé ?

Code:

1
2
3
4
5
6
    rc = WSAStartup(MAKEWORD(2, 2), &wsaData);
    if (rc != 0) {
        /* Could not find a usable Winsock DLL */
        wprintf(L"WSAStartup failed with error: %ld\n", rc);
        return 1;
    }

socket bien crée ?

Code:

1
2
3
4
5
6
7
8
9
10
11
    RecvSocket = WSASocket(AF_INET,
                           SOCK_DGRAM,
                           IPPROTO_UDP, NULL, 0, WSA_FLAG_OVERLAPPED);
 
    if (RecvSocket == INVALID_SOCKET) {
        /* Could not open a socket */
        wprintf(L"WSASocket failed with error: %ld\n", WSAGetLastError());
        WSACloseEvent(Overlapped.hEvent);
        WSACleanup();
        return 1;
    }

socket bien lié ?

Code:

1
2
3
4
5
6
7
8
9
    rc = bind(RecvSocket, (SOCKADDR *) & RecvAddr, sizeof (RecvAddr));
    if (rc != 0) {
        /* Bind to the socket failed */
        wprintf(L"bind failed with error: %ld\n", WSAGetLastError());
        WSACloseEvent(Overlapped.hEvent);
        closesocket(RecvSocket);
        WSACleanup();
        return 1;
    }

14/12/2011, 17h54
jblecanard

[hors-sujet]

Citation:

Envoyé par ouhare

Je jongle entre deux objets version WIN32 et UNIX (avec les macros #ifdef #endif);

Miam miam la portabilité à coup de pré processeur. Je crois que je vais écrire un petit article sur le sujet pour en finir avec ces mauvaises habitudes ^^

[/hors-sujet]
14/12/2011, 18h02
ouhare

Citation:

Envoyé par jblecanard

[hors-sujet]

Miam miam la portabilité à coup de pré processeur. Je crois que je vais écrire un petit article sur le sujet pour en finir avec ces mauvaises habitudes ^^

[/hors-sujet]

que veux-tu dire par Miam miam? :lol:

J'utilise deux objets qui implémentent la même interface, la création de l'objet se fait entre ces deux directives, mais les appels de méthodes sont les mêmes !

Je trouve ca plutot efficace et plutot propre.. on m'aurait menti?

@niglo:

Je me suis inspiré aussi du code trouvé sur la MSDN, donc mon code est quasiment le même que celui que tu proposes.. mise à part les messages d'erreur que je redirige sur std::cerr.
14/12/2011, 19h09
jblecanard

Citation:

Envoyé par ouhare

J'utilise deux objets qui implémentent la même interface, la création de l'objet se fait entre ces deux directives, mais les appels de méthodes sont les mêmes !

Je trouve ca plutot efficace et plutot propre.. on m'aurait menti?

Je résume rapidement car ce n'est pas le sujet du post, mais la bonne manière consiste à écrire deux implémentations (*.cpp) du même (*.h), et de faire sélectionner à la chaîne de compilation le bon fichier *.cpp en fonction de la plateforme. Alors que là tu dois te coltiner une classe mère pour rien. On peut en rediscuter en MP ou sur un autre post.
15/12/2011, 09h34
niglo

Citation:

Envoyé par ouhare

@niglo:
Je me suis inspiré aussi du code trouvé sur la MSDN, donc mon code est quasiment le même que celui que tu proposes.. mise à part les messages d'erreur que je redirige sur std::cerr.

OK, parfait, c'était au cas où. ;)

Peux-tu mettre un peu plus de code de ce que tu fais autour du WSARecvFrom ?
Et aussi (juste pour être sûr) les affectations d'@ IP et port de ton socket ?

Une autre piste : est-ce que tu as vérifié que le port était ouvert sur ton firewall ?
15/12/2011, 15h43
ouhare

bon, j'ai trouvé une solution, apparemment cela venait de la structure WSAOVERLAPPED, (avant dernier paramètre de WSARecvFrom)....

J'ai testé en remplacant la structure par NULL et ho miracle !
tout fonctionne ! :aie:
au passage, je n'ai toujours pas vraiment saisi l'utilité de cette structure...
d'ailleurs le code erreur que la fonction me renvoyait me laisse encore dans le flou...
enfin je pense que pour mon cas, je n'en est pas vraiment l'utilité.

merci encore niglo de t’être penché sur mon problème !
15/12/2011, 16h50
niglo

pas de soucis, si je peux aider !