If you used a vector, there would be no need to reduce every client''s index number when one player leaves. Simply continue on merrily, until there are 0 clients connected. Then, just set your "nextClientID" to 0, so the next client to "connect" gets 0 for thier ID, and go from there. The only real problem there is what happens when 75 clients are on, and a few leave, but a few more come to fill that space up... over a long period of time. You might be able to create a thread when a client connects to do a search for the first availible slot in your vector, etc.

Z.

Why don''t you use a map? It would offer some serious advanteges. No need for searching, just hash some kind of id, like a name, or even the ip.

Hashing is really fast compared to searching, and as long as your map is big enough, you won''t have any perfomance difference whether there are two or two hundred people connected. And because it works with pointers, adding and removing is fast, too.

MadProgrammer

Ok, this isn't writing your code is it, hope not.

1.
a) Build an array of client pointers
b) Fill with NULL

2.
a) Build a stack of client pointers
b) Fill with pointers to each element of the array of clients

3.
a) Receive command
b) Read index
c) Get client with index from the array
d) Do command, like new, delete, move, jump on the client

4.
a) New client
b) Pop client address off stack
c) Make new client at that address
d) Client index is address-array/4, or use the address
e) Send client index

5.
a) Delete client
b) Read index
c) Delete client at that address
d) Set to client at that address to NULL
e) Push address on the stack
f) Send delete to clients

If you use some form of bytecode for commands your packets could be as small as 30+ bytes.

You could also have a stack of active clients, so you wouldn't have to search when building commands. Or you could just build commands and then send them when a set time has elapsed.

So there you have it, no searching, fast adds and deletes, fast command handling. Too bad the client has a 28.8 modem








Edited by - burp on November 29, 2001 9:07:16 AM

to delete a client it should not send its index, beacause thh server already knows the index by looking at the ip from wich the packet came. when you send the index and the server does delete exactly this player in his array, then players could delete other players, by sending another index to the server.

the server always has to check from wich client the packet came, or cheating will be easy, if you just can send data about other players by using their index...

SmG

My method avoids searching a list of ip addresses.

A client must send its index to the server, because the server has no other way to know who its talking to.

The server must send the index of deleted clients to the other clients, because without that command, they wouldn''t be deleted. ie: Quake would be one crowded place.

We''re only talking about one byte here, big deal, or 255 possible clients.

For extra security all commands could be checked, for a valid ip, before processing it. ie: With the clients ip stored in client object on connection. Not sure what the overhead of that would be. Pretty small compared to the network latency.

Also a hacker could be fudged if the clients all spoke different command languages. Not that hard to implement, the processing time would be the same on both sides. Memory usage would increase, but it may be worth the extra cost, if hacking is a concern.

but then you have to check if this index is valid. if it isn''t your programm will crash with a memory access error. my programm is al little bit more complex, because there are different arrays for things like players and for objects controlled by players in the game.

when your app is mulithreadened only one of the threads can have the ability to delete or add players, beacause if one thread is using a player in his array for some reason like drawing or stuff an the other thread deletes this player the programm crashes. there''s no way around it. i tried to stop one thread, wile the other is processing a player, bit this gets very slow with a lot of players.

i''m currently rewriting it for linked lists, because you can delete one element with one line of code and so the posibility of deleting a player wich is in use is very small.

hacking isnt really a problem yet, seeing as i'm *almost* ready to release an ALPHA.

i thing burp is right, i dont wana search the ip's because that would take forever ( O(numClients) every time i get a msg! )
i could check the IP i just got a msg from w/ the ip stored in the client struct
that way i see if someone else is pretending to send the packet and if so, i the pretender to disconnect (hehe)

Edited by - MadProgrammer on November 29, 2001 12:12:10 PM

quote: Original post by SmG
to delete a client it should not send its index, beacause thh server already knows the index by looking at the ip from wich the packet came.

This limits you to one client per IP address, though, which can break in a couple of circumstances.

1) Say you come up with a proxy server so people behind a firewall can play - now there are multiple clients with 1 visible IP address.

2) Say I''m on a PC with two NICs and two different routes to the internet: if my packets switch routes for load balancing, this would screw up my ability to play the game.

You really need to include some kind of encrypted player ID in each packet anyways, because otherwise people will be able to knock others off of the server with some simple IP spoofing.

SmG

That's what the NULLs are for, like I said, I didn't want to write MadProgrammer's code for him, shhhhh.

This method would be able to handle as many sub objects as you wanted, ie: player, missiles, blasts, lasers, whatever. You would just have to use the bytecode to represent the class hierachry.

I agree with Dean Harding, completion ports are the way to go.



Anonymous Poster

I didn't think of that, good point. The ip checking, would only be needed if you feared an attack, for MadProgrammer's alpha I don't think that going to be a probelm.

What about a different random port for every client then, use that for security? Plus random command languages, plus encrypted packets. Overkill I'm thinking.

Edited by - burp on November 29, 2001 12:24:48 PM

what are completion ports?