I have now read a total of 5 different winsock tutorials and I still do not get how sockets work! Could somebody please explain how to make a program that will allow n computers to share data with each other. As an example could somebody make a 'game' with the following rules:

  1. check for the existence of the server (Give it a unique name?)
  2. if it does not exist, create it, you are now the SERVER
  3. if it does exist, join it, you are now a CLIENT
  4. As a server, repeatedly send out "GAME" to each client
  5. As a client in responce send back a string
  6. As a server print all of the recieved strings that are in response to a "GAME" call (add some code to the start of the string?)
  7. As a server, if the string "EXIT" is recieved in response to a "GAME" call, shut down the socket after sending a string.
  8. On socket shutdown, print the exit string recieved by the server if you are a CLIENT.

I really need help, sockets are making no sense whatsoever to me. Thank you.

Recommended Answers

All 10 Replies

First of all, you cannot manipulate names. A name is a property of a computer, and it should stay intact. What you need is to allocate a port over which the game communications would occur. This port number is to be known for all participating computers in advance.

In the discovery phase, the game shall broadcast the request (that is, send a UDP pachet to a said port at a broadcast address). If the server already exists, it shall reply with its IP address. If nobody replies in a sensible time period (and maybe even after a few retries), the game may assume there's no servers, and create one. Keep in mind that nothing happens instanteneously, so there's a possibility that two or more systems may simultaneously decide to become servers. Yuo need a protocol to detect and arbitrate such race.

Once the server is established, the rest is more or less trivial. I'd suggest to set the discovery stage aside for now. Make the server, and have it running at a known IP address. Let the clients connect to that address. Are there specific questions on how to do it?

Props to nezachem. I was going to suggest the same thing. Did a little research on some broadcast tuts and learned that APPARENTLY broadcast is dead, long live multicast. Huh.


Also, don't forget that with any WinSock program you write, you'll need to link in the appropriate library for your compiler. Otherwise, you'll get obscure errors about this or that reference being missing.

I have only just glanced at the multicast stuff, but does that mean that the only thing that I can specify about my socket is it's port? Arent there only 65535 ports available? Doesn't that mean that it will be very difficult to get a unique port for only your program? How can I make my programs connect to just the right host?

APPARENTLY broadcast is dead, long live multicast

Multicast is great after the server is established, whch is not the case initially. I should have emphasize, that everything I said applies to the LAN environment only. It would be very hard (if posiible at all) to implement discovery over pure WAN.

So then, how do games like Call of Duty do it? Clearly they are able to set up a server (host) and clients.

So then, how do games like Call of Duty do it? Clearly they are able to set up a server (host) and clients.

Ever heard of Service Discovery Protocols (SDP), and other systems like Zeroconf and UPnP.

When nezachem suggested that you put the discovery part aside for now, this is not to mean that it is impossible (and games like Call of Duty certainly have a solution to this, either their own or using one of many standard protocols to do this). It's just that the discovery part is a bit harder to do correctly. So, if you are having trouble just making simple socket communications, I also suggest you start by getting that to work (manually starting and configuring the server/client, and then concentrating on getting the back-and-forth communication working), then you can work on a solution for the automatic discovery and establishment of connections.

How do you test a simple socket program though? I only have 1 laptop...

I only have 1 laptop...

Umm... set up few virtual machines there, perhaps.

Just run the client and the server on the same computer. You run the two programs separately.

Assuming you're connected to the internet, then you have an IP address. If you send packets from your computer to your own IP address, then it's gonna work, the packets will simply go to your router / access-point and right back to your computer. The client can send a packet to its own IP address, which comes right back and is picked up by the server. You can get a few conflicts between the client and server if they are listening to the same address and port all the time, so you should use different ports for outgoing and incoming communications (e.g. the server listens on port 4302 and sends on port 4303, and vice versa for the client... you get the idea).

If you can't connect to the internet or a local network of any kind or simply want a faster connection, then use a loopback. This is a virtual device that acts as a network "echo". As in, whatever you send to it, it will give it back to you. This is actually one common way to communicate between programs running on the same computer. On Windows you follow these instructions to enable loopback. Under Unix/Linux, it's always on (or at least, by default) at address as usual.

You really don't need to look very far for this info, the example of MSDN for winsock is one which sets up both a client and a server within the same program and use the loopback (by convention, at IP address for the transaction.

Thanks, I will try to see if I can get it to work... my goal is to eventually be able to create these functions:

void sendData(void *data, size_t datalen, char *IP, int port);
void readData(void *data, size_t *datalen, char *IP, int port);

That should not be too hard once I get the hang of sockets, should it?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.