Winsock server not working on Win7

[shoppinit]

My code worked perfectly in XP, but now that I've ported it to Win7 I can't get my server to accept connections.

Server code digest:

err = WSAStartup( wVersionRequested, &wsaData );
sin.sin_addr.s_addr = htonl(INADDR_ANY);
sin.sin_port		= htons(port);

sock = socket(AF_INET, SOCK_STREAM, 0); //Tried IPPROTO_TCP, too. 

qtest = bind(sock, (SOCKADDR *)&sin, sizeof(sin));

result = setsockopt(sock,  SOL_SOCKET,   SO_REUSEADDR,   (char *) &flag,  sizeof(int));  

test = listen(m_sock->get_sock(), 0);

m_sock->set_com_sock(accept(m_sock->get_sock(), (SOCKADDR *)&m_sock->get_sin(), &sinsize));

When my client tries to connect (either localhost or from another address) the server running on XP unblocks and carries on normally.

On the Win7 machine, accept() never unblocks.

I have elevated everything to administrator level, and turned off the Windows Firewall. Makes no difference. I've tried a couple of different ports.

I am seriously scratching my head trying to figure out what's going on. Any ideas?

[ahoodin]

Can you ping your Windows 7 Box?

[shoppinit]

Yes, no problem pinging it from another address and pinging localhost.

[ahoodin]

Can you run the client on the same Windows 7 Box and connect/accept?

[shoppinit]

I can run the client on the Win7 machine and connect to a server on an XP machine, but not vice versa.

[ahoodin]

What i meant is can you run the client on the Windows 7 box and connect to the server running on that same box?

[shoppinit]

I can't connect to the server on the Win7 machine. Either from the same machine or another machine.

Interestingly if I use currports to see what is happening, it shows my server as "listening" and my client as "Established", yet the server blocks on accept(). On the XP machine, accept() unblocks as soon as the client makes the connection.

[shoppinit]

OK, I have made some slight progress. I can now connect to the server running on the Win7 machine from the XP machine.

Or I can connect to the server running on the XP machine from the Win7 machine.

I can connect to the server on the XP machine with the client on the same XP machine.

What I CANNOT do is connect to the server on the Win7 when the client is running on the same Win7 machine.

Any ideas? However unlikely? I can't figure it out at all.

My hosts file is OK (it seems): I added localhost to my hosts file just in case, but it makes no difference.

[ahoodin]

What did you have to do to connect successfully from you XP box to you Win7 box?
What was the solution to that problem? FireWall?

[shoppinit]

No, the firewall was not an issue. That was the first avenue I explored. I don't know why is started working as described above. However that didn't help me much because I need both processes (server and client) to run on the same machine.

I have now rewritten the client code using getaddrinfo() to give me the socket and address info, and despite this info being exactly the same as my previous functions, it now works.

For info, here is the old client code snippet:

sin.sin_family	= AF_INET; 
sin.sin_addr.s_addr = inet_addr(cp); //(const char* cp  )
sin.sin_port=htons(p_port); //(const unsigned short p_port)

WSAStartup(MAKEWORD(2,0), &WSAData);

sock = socket(AF_INET,SOCK_STREAM,0);

err = bind(sock, (SOCKADDR *)&sin, sizeof(sin));

err = connect(sock, (SOCKADDR *)&sin, sizeof(sin));

[shoppinit]

Replaced by:

hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;

int iResult = getaddrinfo(m_IP.c_str(), m_port.c_str(), &hints, &result);

sock = socket(result->ai_family, result->ai_socktype, result->ai_protocol);

err = connect( sock, result->ai_addr, (int)result->ai_addrlen);

where connect() unblocks accept() on the server and all the parametres are the same :| Bizarre.

My thinking is that something is going on behind the scenes that is less tolerant to ambiguous calls in Win7 than XP.

[shoppinit]

What did you have to do to connect successfully from you XP box to you Win7 box?

I forgot to mention that I had been using VS2010 pro that i was evaluating. I uninstalled it (in disgust - thank goodness I tried it before buying) and went back to VS2008. That may explain why it suddenly started accepting connections from other machines or it could be a pure coincidence.

[MikeAThon]

What was the purpose of the call to bind() on the client side. A call to bind() on the client is almost always wrong, although in most cases it usually ends up doing nothing.

Mike

[shoppinit]

I'm afraid I can't remember why I coded it like that. I'm sure I would have used example code from MS then developped from there. Either way, since a call to send implicitly calls bind I tested by commenting it out which made no difference.

[MikeAThon]

... Either way, since a call to send implicitly calls bind I tested by commenting it out which made no difference.

No, that's not correct. A call to connect() will bind the socket, but a call to send() will not. In fact, the docs specifically state that bind() is NOT implicitly called by a call to send():

The bind function is required before the use of the send or WSASend functions which do not perform an implicit bind and are allowed only on connected sockets, which means the socket must have already been bound for it to be connected.

See "bind Function" at http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

The reason I am fixating on this issue is to try to explain why things suddenly started working for you. The call to bind() might have made a difference if your Win7 box was multi-homed (two or more network cards) whereas your XP box was not (or vice versa).

But the more I think about it, the call to bind() is probably not the culprit.

The issue might be changed behavior as between XP and Win 7 on the SO_REUSEADDR option. This is a seldom-used option (are you certain you need it?) Around XP, it was recognized that it also was a huge security issue, and MS introduced the SO_EXCLUSIVEADDRUSE option.

Read about it here: "Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE" at http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Perhaps the changed behavior in SO_REUSEADDR is the reason for code that works in one box and not the other.

Mike