DescentBB

Hi,

I am planning to add TCP/IP support to d2x-w32 and therefore need some insight on WinSock.

Here's what I have understood so far:

The server needs to create a "base" socket with the socket() function.

To find out whether a client is trying to connect, the server has to create a listening socket on its port using bind() and listen() and has to check that port for incoming connection requests using the select() function. To be able to poll the listening socket and not get stuck on it, the listening socket must be non-blocking.

To actually communicate with clients, the server has to create additional sockets ("channels") using the accept() function. So the server has one base socket plus one channel socket for each client it is connected width.

The client simply has to create a socket and call the connect() function with the proper IP address and port number of the client.

Once server and client have a connection, they can exchange data over their linked channels. To check whether a channel is ready for sending or receiving data, they can call the select() function.

Is this all correct? If not, what do I have to change?

Looks good to me, at least from my experience with UNIX sockets.

Actually, now that I think of it, you don't need the socket non-blocking if you're using select(). The entire point of select() was to get rid of making it non-blocking.

Unless that's a specific requirement for WinSock rather than UNIX sockets, and unless you're using it, you should probably get rid of it.

You're right, if I use select() i get around the blocking stuff. Read it yesterday night on some website about TCP/IP.

I've however been explained that UDP/IP, which already is in D2X, is all that is needed for internet play.

Unfortunately the UDP/IP implementation in D2X only seems to browse a local network for servers, thus not requiring and explicitly specified IP address and port number. Now I have to see how to make the code directly operate on some user-specified IP address and eventually make it listen on other device besides a network adapter (e.g. modem).

UDP/IP will also allow for faster games than TCP/IP, because it doesn't retransmit data that doesn't get through.

I know, but that doesn't help me. I just need to find out where to "persuade" D2X's UDP code to use a certain IP address.

for this, I'd look into what DirectPlay offers.

I will not start to integrate DirectPlay into D2X, when there's a UDP available already which I only have to tweak a little.

UDP/IP allows for local network broadcasts (as you already know). I imagine that when a netgame packet comes in via this, it displays the information garnered from that packet on the list, and when you select it, it just connects to the IP that it came from. So just look for where that code is and add code to make a window which asks for the IP/port you want to join, rather than reading it out of whatever array.

Put the option for joining a specific IP in the Netgames menu. And definitely include a list of previously joined IPs, and maybe also a "favorites" thing which is modified only by the user. Shove them into a seperate text file, like udpaddrs.txt or something. That'd make it much easier for poor people with single monitors and are too lazy to write down IPs, hehe. Maybe also include the ability to paste from the Windows clipboard. Which is actually pretty easy to interface with, mostly just a matter of making it platform-independent. #ifdef I guess

Isn't D2X-W32 platform dependent anyways?

Yeah, the whole "W32" part kinda gives it away.

Diedel, the local UDP/IP code is probably because of the way D2 finds servers. I'm pretty sure it broadcasts a "Hello?" message out there and then waits for replies. Each reply constitutes a game server.

Diedel wrote:Unfortunately the UDP/IP implementation in D2X only seems to browse a local network for servers, thus not requiring and explicitly specified IP address and port number.

How's this going? Sounds like this should be the simple part, all you need is to circumvent the browsing code and read the IP.

Diedel wrote:eventually make it listen on other device besides a network adapter (e.g. modem).

Why would you want this to work on anything but a network adapter?

MehYam wrote: is to circumvent the browsing code and read the IP.

Diedel wrote:eventually make it listen on other device besides a network adapter (e.g. modem).

Why would you want this to work on anything but a network adapter?

So it has the same functionality as the orignal DOS D2. I do understand your point tho...

"I'm pretty sure it broadcasts a "Hello?" message out there and then waits for replies. Each reply constitutes a game server."

If that were the case, LAN netgames would show up on the list almost instantly (it'd be weird if the game server didn't respond to such an information request right away), but they don't. Having the game host broadcast presence packets periodically saves a fair amount of bandwidth and processing time over sending the info on-request, particularly in situations where you have multiple clients listening for netgames. Just think: 12 netgames per socket in D2, and 10 people viewing the same socket... An info request system would perform horribly in a situation like that over dialup (Kali anyone?) and on slow LANs.

The IPX address of the sender is included in the broadcast packet; this is how Descent knows who to talk to when negotiating a connection. The UDP/IP implementation almost certainly works in a similar manner.

bah, this makes me want to go digging

All problems solved, UDP/IP netgames fully working. There were some pretty nasty problems I had to deal with though, like a game hosts local IP address not being the IP address it was communicating over, and other mean little things. Works great now.