I'm trying to set up my game so that it can run easily on a LAN. It's written in C++, for Windows, uses non-blocking sockets and is for 2 players. I've read through various tutorials, the FAQ, and articles, and think I have a grasp of the theory behind using UDP and running LAN games. I'd like to run it by you guys to see if I'm close (or totally off base here). Let me know if this is or is NOT how I should do it: -Computer A starts broadcasting UDP on the broadcast address (using sendto()), every several seconds. This broadcast includes an ID unique to the program and an ID unique to the computer. -Computer B starts trying to listen on the broadcast address (using recvfrom(), with the *from parameter being the broadcast address). For the next several seconds, it keeps track of all the messages it has received with the program ID. It then reports the list of all the unique computer IDs that sent the broadcast message with the program ID. -The user of Computer B chooses which computer it wants to play with by choosing the computer ID it wishes from the list the computer has reported. Then Computer B sends a message on the broadcast address which includes the program ID, its unique computer ID, and a flag confirming it wants to start playing. -From then on, both Computer A and B talk to each other by sending messages and reading messages from the broadcast address (with sendto() and recvfrom(), using the broadcast address as the parameters for *to and *from), which include the program and computer IDs. The use of broadcast address is so that the computers can talk on the LAN, and the computer IDs (randomly generated numbers chosen by each computer on program startup) so that multiple LAN games with this program can be running at the same time, without interfering with each other. Please let me know if this is correct. Thanks. -Gauvir_Mucca

The main problem I see with networking is that it is too closely related to AI. What I mean by this, is that each of your computers (A and B) don't know what to do when they start executing. You say that "Computer A starts broadcasting" and "Computer B starts trying to listen"... are those the same programs? They can't be because they do different things.
I did this exact thing a while back. You will probably want to broadcast for a couple seconds, and if you don't get any replies, become a host and start listening for broadcasts.
Then you say "Computer B chooses which computer it wants to play with". Is Computer A forced to accept?

I would suggest not using broadcast for your game. Use it to connect to find the server, then just send to the specific computer. This is especially true for a 2 player game. The only reason you would want to continue broadcasting is to lessen the upload bandwidth and make the router do the work by replicating the packets. If anything, I would not use broadcast because it is not scalable.

I've written a few simple matchmaking servers. Its very nice for 2 players to be able to connect from anywhere, but there are a lot of problems that need to be solved. NAT punchthrough, dynamic routing, networks with daisy-chained routers, etc. I learned more about networking from programming matchmaking servers than anything else.

Well, once Computer B sees Computer A's broadcast and is told to start a game with that computer, how does it sendto() and recvfrom() that computer specifically? It's my understanding that broadcasting is the only way to communicate using UDP across a LAN, if you don't know IP addresses beforehand.

Once Computer B receives a broadcast from Computer A, is it possible to deduce the IP of Computer A and send future messages exclusively to that computer? And likewise, can Computer A then deduce the IP of Computer B and then send and receive messages exclusively from that computer? How?

Might not want to have it be a random number, if only because you've only got so many of those, and sheer chance of two computers just happen to generate the same 'unique id' at random is a realistic, and rarely reproduced error. Might want to shoot for something a little more actually unique, like [since you're using a lan], the sources IP address [or ip address/port group] :P, or even a complete name.

Quote:

Original post by Gauvir_Mucca Well, once Computer B sees Computer A's broadcast and is told to start a game with that computer, how does it sendto() and recvfrom() that computer specifically? It's my understanding that broadcasting is the only way to communicate using UDP across a LAN, if you don't know IP addresses beforehand. Once Computer B receives a broadcast from Computer A, is it possible to deduce the IP of Computer A and send future messages exclusively to that computer? And likewise, can Computer A then deduce the IP of Computer B and then send and receive messages exclusively from that computer? How?

Unless you are using tcp/ip, you should always receive your packets with the recvfrom() function. And that function will give you the SOCKADDR_IN of the sender so you can use it to reply.

Broadcasting has a very limited usage. Its only good for finding other machines running the same software. It would be nice if multicasting was more supported.

I'm assuming that the user initiates computer A as a "server" waiting for connections, and that another user initiates the selection of a server to connect to on computer B.

Very old networked games worked like that (for LAN play). The main limitation is that every port on a network switch needs to forward every broadcast packet.

Thus, for actual game content, I would recommend using sendto() to the actual server address (not the broadcast address), and have the server send individual packets to each connected client, containing all of the updates coalesced. If you want to run, say, 4 separate game instances on a single LAN (assuming your typical network switch topology), you'll quickly realize why this is better from a traffic standpoint :-)

Last, it's simple to let the server broadcast every N seconds, but it adds unnecessary latency in finding servers. Instead, have the server not broadcast, but instead, the client, when looking for servers, broadcasts a packet every N seconds asking for servers to reply, and a server, when seeing such a packet, broadcasts a reply.

I have an article that goes further into how to do robust LAN matchmaking.