next »

[Indievelopper]

Hello everyone!

I've got a problem using Berkeley sockets.

First of all, my little piece of code :

Code:

#include <winsock2.h>
#include <iostream>
#include <stdio.h>
using namespace std;

int main()
{
    WSADATA wsaData;
    WSAStartup(MAKEWORD(0,2) , &wsaData);

    SOCKET sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); //INVALID_SOCKET?
    if(sock == INVALID_SOCKET){
        cout << "wtf..";
    }
    int x = 1;
    unsigned long val = 1;  // 1 = NONBLOCKING , 0 = BLOCKING
    setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char *)&x, sizeof(x));
    //ioctlsocket(sock, FIONBIO, &val);

    struct sockaddr_in sa;

    sa.sin_family = AF_INET;
    sa.sin_addr.s_addr = ADDR_ANY;
    sa.sin_port = htons(1100);

    if(-1 == bind(sock, (struct sockaddr *)&sa, sizeof(sa))){
        cout << "BUG";
    }
    _sleep(1000);
    while(listen(sock, SOMAXCONN) == SOCKET_ERROR){
        cout << ".";
        _sleep(200);
    }
    cout << "meh!";

    return 0;
}

So yeah, it does print "wtf.."

I've tried everything, even if the rest of the code was wrong, why does the socket() function return INVALID_SOCKET? I've looked on wikipedia, on my "Game Coding Complete 3rd edition", it's always the same, this should work.

I'd be very pleased if you could help me with that   .

[Endurion]

This one always worked for me:

Code:

m_Socket = socket( AF_INET, SOCK_STREAM, 0 );

[mewse]

You're not checking the return code of your call to WSAStartup().  If it's not zero, then starting up WinSock failed, and all subsequent WinSock calls will fail.

You can find the possible error codes for WSAStartup() here.

Additionally, you should modify your error handling code to be like this:

Code:

if(sock == INVALID_SOCKET){
        perror("socket");
    }

"perror" is a useful function which will print out a human-readable error string, for these sorts of functions.  (In this example, it'll show up as "socket: <error message>").  Doing this will at least give you a better idea of what's going wrong, than simply printing "wtf..."!

[Average Software]

Windows sockets aren't Berkeley sockets.  They're pretty close, and most of the documentation you find will work, but they're also different in very annoying little ways.

[mewse]

Like not having a "poll()".  For real, Microsoft?  You reckon that "select()" is good enough, do you?   

[Average Software]

Like not having a "poll()".  For real, Microsoft?  You reckon that "select()" is good enough, do you?   

That exact problem bit me in the ass just two days ago.  They're not different enough to justify having multiple source files, so I have several #ifndef __WIN32__ ... #else ... #endif blocks scattered through my network code.  Annoys the hell out of me.

[lansing]

Like not having a "poll()".  For real, Microsoft?  You reckon that "select()" is good enough, do you?  

They've had a poll for about 4 years now.
WSAPoll appeared in Vista.

*edit* deja vu.

[mewse]

They've had a poll for about 4 years now.
WSAPoll appeared in Vista.

"WSAPoll()"?

Yay for Microsoft randomly adding prefixes and suffixes onto long-standard function names.

Still, it may have taken them twenty years, but at least they did finally get there in the end. 
Even if they managed to screw up the function name.

Maybe in another twenty years, they'll get around to fixing that bizarre non-standard function prefix.



Plus, as you point out, WSAPoll  isn't actually supported on anything before Vista, which means that if your game uses it, then your game won't work for people who are running XP or earlier.  Which means from a purely practical point of view that the function still does not exist in any practical sense.

[Garthy]

That exact problem bit me in the ass just two days ago.  They're not different enough to justify having multiple source files, so I have several #ifndef __WIN32__ ... #else ... #endif blocks scattered through my network code.  Annoys the hell out of me.

One of the first things I do with a body of code using sockets in any significant way is to quickly wrap them up in a lightweight abstraction/API of some sort. This generally removes the need for a whole bunch of switching ifdefs throughout the whole body of the code, and is *especially* useful if the code is to be cross-platform- it is simply stunning as to the number of tiny differences between platforms when it comes to socket APIs. Without such a thing, in a project of decent size you can be left with a series of increasingly complex and poorly-understood nested preprocessor defines, all through the code. If you pull it to one place, you can make global changes to the whole system on discovering a problem quickly, and can properly document all the weird socket hacks you need to do for different systems in the one place. Oh, and when it comes to socket APIs, the Windows one is in a horrifying league of its own.

Anyway, such a thing would bring the complexity from your app into just one file, and avoid polluting the rest of the app with a series of switches to cope. It's not advice I'd give to someone just starting out, as it's better to get your hands dirty initially, but once you've got a (bitter) taste it's something I'd highly recommend.

[Average Software]

That exact problem bit me in the ass just two days ago.  They're not different enough to justify having multiple source files, so I have several #ifndef __WIN32__ ... #else ... #endif blocks scattered through my network code.  Annoys the hell out of me.

One of the first things I do with a body of code using sockets in any significant way is to quickly wrap them up in a lightweight abstraction/API of some sort. This generally removes the need for a whole bunch of switching ifdefs throughout the whole body of the code, and is *especially* useful if the code is to be cross-platform- it is simply stunning as to the number of tiny differences between platforms when it comes to socket APIs. Without such a thing, in a project of decent size you can be left with a series of increasingly complex and poorly-understood nested preprocessor defines, all through the code. If you pull it to one place, you can make global changes to the whole system on discovering a problem quickly, and can properly document all the weird socket hacks you need to do for different systems in the one place. Oh, and when it comes to socket APIs, the Windows one is in a horrifying league of its own.

Anyway, such a thing would bring the complexity from your app into just one file, and avoid polluting the rest of the app with a series of switches to cope. It's not advice I'd give to someone just starting out, as it's better to get your hands dirty initially, but once you've got a (bitter) taste it's something I'd highly recommend.

This code is in my abstracted API.

[Garthy]

This code is in my abstracted API.

Good to hear. In that case, let's treat my post as a suggestion for people who have had to deal with a large body of messy code that doesn't yet do such a thing, or a things-to-consider-later post for those just starting out.