Fonction WSARecvFrom fail..

**ouhare** · 12/12/2011, 16h18

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 :

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

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 :

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

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 :

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

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.

**niglo** · 13/12/2011, 14h04

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 ?

++

**ouhare** · 14/12/2011, 13h17

DATA_SIZE est une macro perso, elle vaut 1024, mais la fonction plante avant même une quelconque réception de données...

**niglo** · 14/12/2011, 13h43

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

**koala01** · 14/12/2011, 13h55

Salut,

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

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

**ouhare** · 14/12/2011, 15h55

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 :

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

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

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

**koala01** · 14/12/2011, 16h02

Envoyé par ouhare

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

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)

**niglo** · 14/12/2011, 17h31

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

Sinon, plusieurs choses à vérifier :

Winsock correctement initialisé ?

Code :

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

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 :

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

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 :

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

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

**jblecanard** · 14/12/2011, 17h54

[hors-sujet]

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]

**ouhare** · 14/12/2011, 18h02

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?

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.

**jblecanard** · 14/12/2011, 19h09

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.

**niglo** · 15/12/2011, 09h34

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 ?

**ouhare** · 15/12/2011, 15h43

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 !

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 !

**niglo** · 15/12/2011, 16h50

pas de soucis, si je peux aider !

Fonction WSARecvFrom fail..

C++

Discussions similaires

Partager

Partager