You don''t identify clients just based on IP, you identify them based on IP:port. This solves the proxy/NAT issue. I would also be surprised if packets could switch NIC''s (and thus IP:port) once the socket was bound (which it will be after the first sendto). If that were possible NAT''s wouldn''t work at all for any machine with multiple NIC''s.

As several people have pointed out, if you don''t want to have a client number in your packets there are better data structures than a random vector or linked list. Searching for the client based on recieved IP shouldn''t take more than O(log(numclients)) which is lots better than O(numclients) if you have lots of clients.

Completion ports are what Windows NT/2000/XP based servers use to avoid the one thread/process per client way of doing things while still getting the advantages of using multiple threads. There is lots of info in MSDN about them.

-Mike

do i hafta be using 2k or XP or NT to use completion ports? i am running 98se at the moment.

1. anyone running two nics on the same machine with two routes to the net is crazy anyway, but easily handled. simple force the socket to be bound to a specfic nic. load balancing or not, the packets for that program will only be allowed to travel on that nic and no other nic will see them. that takes care of that problem quickly.

2. using encrypted player ids is nice and all, but you will always have to validate that every packet is coming from a particular ip:port pair. most systems use a combination of tcp and udp (tcp sends have to send messages over the link like text messages or other data that can never be lost due to dropped packets (also useful for keeping players in sync every 2 seconds or so)) this link since its connection based (and established after the udp handshake is complete) is used to handle player id stuff (player ids should never change while connected). if player''s send things like quit messages, they must be sent via the tcp connection (which wont need to be validated since it is a connected server/client ip:port pairing). udp can be used for updates of players sending movement/firing/control and other commands that can be "made up"/extrapolated if dropped.

3. the server should use non-blocking sockets with select() to ensure all the sockets that are ready are handled. this section should be in a seperate thread (while the main game code is in the main thread)

4. dont full yourself into thinking that just because this is an aloha that you can slack off and not do the network stuff correctly (or at least partially correctly). the worst thing to do is not care about security until later on in the project when it is too late (since it requires rewriting major portions of the netcode).

btw going through all the clients in the linked list is not that time consuming (even with 75 clients). you probally waste more cpu resources in other parts of your code. just make sure your comparision of the ip:port pair is fast.

i posted a while back about using a tcp socket for every client & and UDP socket, too, and ppl said it was a bad idea. is it? it would really take care of my problem w/ writing code 2 ensure that packets arrive.

If you''re going to ask for help, pick a language and use it right. We can''t all be l337.

*correctly.

wtf are you talking about?

I/O completion ports are only supported on NT/2000/XP. You wouldn''t want to run a server on 98 anyway - it''s just not stable enough...

Mind you, if you''re still in the developement phase, then you might not be able to get a 2000 machine to test on. I recommend you try, though. Or even XP is pretty good.

codeka.com - Just click it.

ip/port comparisons should be extremely fast. After all, you are only comparing 4-byte and 2-byte values. It isn''t like you have to do a string comparison.

Also, in regards to security, most games use a modified CRC32 algorithm, which is very fast and quite reliable. Using MD4/5 is not acceptable speedwise so CRC32 is a better solution. The only problem with CRC32 is that you need modify it slightly so that your average Joe-hacker can''t simply look up the code on the net You could technically just choose a different polynomial but that number could probably be determined by brute force over time.

Dire Wolf
www.digitalfiends.com

For some reason, the best solution has been passed over without further comment... use a map data structure and hash the address/port pair. It''s fast and reliable. No need to send extra data over the network.

If you want to use both TCP and UDP, you need one tcp listener socket, one udp socket, and one tcp socket for each connected client.