Broadcasting availability

Hey, I've been thinking about this a long time... But if you have a multiplayer game, how do you get a list of servers currently hosting? I read in Winsock 2.0 (Lewis Napper's book) about network services and stuff, and I was just wondering if you could use one of those SAP or whatever namespaces to broadcast that "This here IP address is a server for (application name here)!" over the internet, so that clients around the world could do a search and generate a list of all servers online.

Also, is the same thing possible by having a website-based listing server, where a server adds itself to a list on a website through some PERL or PHP script (I really don't know how that stuff works) and clients can then access that list through HTTP?

AFAIK, most major multi-player games have centralized servers that all other servers contact. Then, in order to get a list of servers, the game client contacts the central server to get a list of other servers, and then query each separate server individually.

Master servers are used in Internet games.

In LAN games, multicasting is used to send a message to a group of PCs, check out this:
http://www.gamedev.net/reference/art...rticle1587.asp

But, multicasting relies on all computers running on the same subnet, I believe. He wanted to do this over the Internet itself.

>>most major multi-player games have centralized servers that all other servers contact
Yes, I knew that (I play Counter-Strike and Starcraft, and sort of guessed about WON and Battle.net). But since I don't have any computers that I can leave on 24/7/365.24, I was just wondering if there's any other way of doing it

Actually, I was reading about some CGI scripts and they mentioned that they read from and save to a text file on the web server, i.e. for web counters etc... Then maybe a client could just send a request for the text file from the website, to get a server list. Does this sound plausible enough for me to go and learn CGI (and what's the relationship between CGI and PERL anyways, or PHP)?

Originally Posted by Hunter2

Actually, I was reading about some CGI scripts and they mentioned that they read from and save to a text file on the web server, i.e. for web counters etc... Then maybe a client could just send a request for the text file from the website, to get a server list. Does this sound plausible enough for me to go and learn CGI (and what's the relationship between CGI and PERL anyways, or PHP)?

Yeah, that'd work.
The server should update their entry in the list from time to time, so that crashed servers will eventually be removed.

But that still requires that a computer be up 24/7 to run the web server, so I don't see what the difference is.

Originally Posted by XSquared

But that still requires that a computer be up 24/7 to run the web server, so I don't see what the difference is.

It's possible to register for a web hosting plan and host the scripts, or even use a free PHP/MySQL web host.

OTOH, I'm not aware of any hosts that will let you run a game server.

Originally Posted by glUser3f

It's possible to register for a web hosting plan and host the scripts, or even use a free PHP/MySQL web host.

OTOH, I'm not aware of any hosts that will let you run a game server.

well he dosent need hosts to run the game server just hosts to keep track of the game servers... even a free web host with PHP/ASP/CGI support can be used to achieve this.... assuming that he server is custom written by you so that it knows where to register...

>>But that still requires that a computer be up 24/7 to run the web server, so I don't see what the difference is.

Well, I already have free web hosting at web1000.com, and (I think) they support CGI scripts, but I doubt they'd let me run a central multiplayer game host-listing server. [edit]And, vasanth, yes this is for a server that I write myself (otherwise there'd probably already be a central listing server).[/edit]

>>The server should update their entry in the list from time to time, so that crashed servers will eventually be removed.

That's a good idea, thanks for the suggestion.

But my other question still remains, what is the relationship between CGI and Perl? Googling on CGI tutorials turns up a list of stuff on "How to do CGI with Perl". Are there other options, or is Perl the best one to go with, or is there something altogether different from CGI that I can use?

You can use any language that supports standard I/O to do CGI, like Perl or C. Let's say that you wrote a program in C and placed the binary (named program) in cg-bin directory, when the URL /cgi-bin/program is requested, the web server executes your program, passing GET/POST data to it, then, the program's output is sent back.

Oooh, so I could just use C++ to write a quick exe that parses argc and argv in main() and that would do the trick?... But how then does the output get sent back, or does cout get redirected or something?

**EDIT**
Ok, after some searching I seem to have found a good tutorial. Thanks everyone!

GET and POST vars are passed through env variables, so you can use getenv and putenv.

The easiest way to do it (not necessarily the best one) is to write a program that manages a list of IPs and request date/time, when a client requests the list, the program goes through it, removes old entries, then adds/updates the client IP and request date/time to the list, and sends the list to the client.

The client should request the list every while to make sure that its IP is still in the list.

All can be implemented using file I/O.

Reading tutorials before starting is always a good idea Good luck

>>when a client requests the list, the program goes through it, removes old entries, then adds/updates the client IP

Yes, I was thinking this a short while ago and I was about to post the idea (boy, was I ever original ). Actually, only the servers' IPs should be listed; I was thinking that a server would send an 'update/add' request, causing a update/cleanup, and client would just cause cleanup (since no update is needed for client) and receive a list.

Since the script only gets run once per request though, I can't think of any other way it could be implemented.

>>Reading tutorials before starting is always a good idea
Well, actually since I'm not working on any networking projects at the moment, this particular idea will probably sit on the shelf for a while before I start on it. But it's good to know what can be done if need be, although I'm having fun reading this tutorial that I found anyways

NOTE: THIS THREAD HAS BEEN DEAD SINCE 2004. I'M JUST POSTING AN UPDATE TO THE STATUS OF THIS IDEA, WHICH I RECENTLY TOOK FROM THE SHELF AND DUSTED OFF.

I've had a *lot* of free time lately, and I've finally gotten a chance to read a PHP tutorial and an SQL tutorial (w3schools). After a few days of tinkering, including reading the tutorials and finding a suitable web host, I've managed to get this idea working very nicely. I set up a web interface here for demo purposes. Feel free to try it out!

I signed up for a free hosting account with awardspace.com (5gb traffic, and no banners!), which supports both PHP and MySQL, and wrote a short PHP script taking the following 'commands' via the 'GET' method:

add: Client's IP is stored in database (as seen by the web server), together with 'app id', 'max clients', 'server name', and a timestamp. If an existing appid is specified for a given client IP, the entry data/timestamp is updated.

rem: Removes client IP/appid entry from listing, or all apps matching client IP if no appid specified

get: Runs a 'DELETE' sql query to prune all records with timestamp older than N seconds, then runs 'SELECT *' sql query and spits out a tab-delimited list of all remaining database entries.

I've been using this in conjunction with 'curl' looping every 10 minutes in a shell script on my laptop to keep track of my IP from work, so that I can log in via SSH

GENERAL NOTES:
Before releasing such a setup to the public, i.e. for a game, of course, the protocol would at the very least have to be modified to use some form of password authentication when running 'add', to prevent malicious false population of the listings. Encrypted challenge-response authentication would be better, but *much* harder to do I think - especially trying to simulate a fully interactive two-way session through PHP. A possible scheme I can think of is:
1. Send a 'whats_my_ip' request to the server.
2. Mangle the response by some predetermined algorithm, and send a 'list_my_ip' request using this mangled string as a password.
3. The server receives the second request, performs the same mangling, and determines if the client actually knows the correct mangling algorithm, listing its info if authentication succeeds.

This could be easily bypassed by capturing the authentic response and duplicating it, since IP's remain static at least until the next disconnect from the ISP.. so, perhaps a better solution is to use the current listing (or a hash of it) as the string-to-be-mangled, which ironically would mean that the security would increase with the popularity of the app. Either way, much more difficult than a (long) static password.

Whatever. I haven't implemented any of the above yet, but I might if I'm eventually motivated to I think, for limited-circulation releases or releases that you don't think will live long (i.e. something you've thrown together for use with a group of friends), this kind of PHP/SQL scheme is a dirt-cheap and easy way to give any internet app awareness of its peers. All you need is a free web host that supports PHP and MySQL, and the amount of PHP/SQL knowledge needed for the task is trivial - especially knowing C/C++.