Server question

Hmm.. That depends on the type of the game you're creating... With UDP server you don't need to use select() at all.
Anyway you can override the 64 descriptor limit (64 is just a default value, and you can #define FD_SETSIZE before you include winsock2.h to match the desired number of socket descriptors you want to handle with select())...

Check this link:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/select_2.asp

"I'll be Bach!" (c) Johann Sebastian Schwarzenegger

[edited by - x33 on May 10, 2003 2:18:05 AM]

I know this is a GameDev forums, and I use it for that most of the time, but this specific project is just a chat server (with fully functional clients, of course ). It would only operator on my school's LAN, and they have already agreed to let me try it out if (and only if) teachers can stop and kids in their room from connecting (luckily for me, the IP's for each computer are: 172.16..). I want to use things like smileys and whatnot in it, but that is further down the road. I need the essentials first :D.

So, up to 200 clients (255, since that is a nice number), each sending about 300 bytes of data every 15 seconds (I am very pleased with my application protocol). It uses TCP, for I have some serious issues with UDP ( >:| ).


While I am here, I might as well ask people's opinions on my Application Protocol (in development). Each message/transfer/whatever is completely split up into up to 255 parameters, each 2^16 (0xffff) bytes long. Each parameter can be anything, from text in a chat message, to the changing status of a client.

Structure of a Data Transfer:
(total_msg_size)(len1)(param1)(len2)(param2)

total_msg_size would be a DWORD telling how large the actual message is. Each lenX is a WORD, and, as I said, each param is up to 2^16 bytes long. They do not have to be ASCII, but can be of any encoding the coder chooses. You can send entire structures this way (if they have a function that puts them into a u_char array). Upon being received, the message is parsed from its array-of-bytes state to a DWORD, WORD array, and BYTE* array. Those three things are then passed onto a handler (the way they are written is much like a Win32 message pump), and does whatever it needs to do.

[edited by - zackriggle on May 10, 2003 3:49:35 AM]

I don''t think 2^16 parameters is a good idea, because a user can easily generate fake-packets and crash your server as it will not be capable of tranceiving/operating with such a big amount of data because of high bandwidth/processor load. Lowering maximum message length would make it ok.
Everything else is fine.

"I''ll be Bach!" (c) Johann Sebastian Schwarzenegger

Yes, but the odds of someone in a countryside high school knowing how to spoof packets on the highschool''s LAN are slim to none. Besides that, it is probably a good idea to take the 65Kb down to something smaller. Perhaps 4Kb (0x100). That would be the easiest. On-and-a-half bytes in size, but it is workable.

Alright, that''s all I really needed to know, thank you.

I am still looking for a WSAAsyncSelect() example...

I know from bitter experience that you can now get tools to monitor packets and to repeat these packets in sequence.
On a test multiplayer game server I''m running at the moment someone was abusing the test and using it to swear in open chat. No problem, I banned the IP address and everything goes quiet for a short while.

The next thing I know the server is suddenly bombarded with several thousand connection requests per second. After the initial connection was made the connection would hang open until the server got bored and forgot about the connection.

This isn''t a trivial thing to do, the connection procedure used to consist of three UDP packets, the first a challenge, then a response from the server then a response to the response containing an ID in the response. This procedure was developed to try to avoid someone spoofing a single UDP packet and using the server to then spam packets back to the spoofed address. (Side note: A few other multiplayer games written last year used to spam large quantities of data in response to a single small UDP packet.) Now the connection procedure is different and has even more sanity checking.

After a few days of tracking the person down via their ISP it turns out these packets came from a utility that enables programmed/recorded packet sequences to be sent out automatically. No programming or very many brain cells were needed by the person in starting the packets.


--
Martin Piper
Network programming made easy with ReplicaNet
http://www.ReplicaNet.com/