Original Post
While reading through the forums earlier I came across something that I''m having trouble figuring out. Basically what was said is this.
When sending packets to a computer it can be a good idea to number the packets sequentially if you need to know if a packet arrived out of order. I can see needing to do this in order to send chat messages in a game or for file transfers. They said that basically Client sends packet 1 and server expects packet 1. If the server receives a packet earlier than what was expected then it was a duplicate and can be thrown away. If a packet later than the one expected arrives then it is put into a buffer for holding until the time when it is used. So based on this, both machines would need to keep a backlog of packets sent so that if for instance the server recieves packets 1,2,3 and 5 then it puts 5 into holding until 4 arrives. I''m guessing that if packet 4 doesn''t arrive then the server sends a message telling client to send packet 4 again because it never arrived. A question on this is, how many packets should we prepare for. Should I have a buffer for 3 packets, 5, 20? Or is it simply that the server will demand packet 4 before it will do anything with packet 5 and won''t accept any new packets until packet 4 arrives?
Also, this is easy to visualize for a single client. But when using UDP where you have no direct connection I will have to examine each packet to see where it came from then based on where it''s from I examine the packet number to make sure it is in order. So potentially I am going to need a buffer for every single client to handle. Is this correct?
So now let''s say that my program sends 4 different types of packets. 1) Non critical movement requests. If we lose one then we don''t really care as we''ll just adjust with the next one. No buffer needed for these. 2) Chat packets. We care about order here and we care that they all succeed so that''s one buffer. If I limit the number of maximum characters a person can type before sending then I will only need a buffer of at most 2 times the size of the largest possible chat packet. Chat packets can be varying length but you have to plan for the worst right?
3) Will need critical packets that are sent when the client makes requests that MUST reach the server. Things like request to change armor and such. These must arrive but do I need to care what order they are received in? Or can I just handle these in whatever order they arrive in? Also monster.died packets are critical I would think as well as a few others that fit into #3. Then 4) packets for file transfer are critical and have to arrive in order or they are useless. This is the hardest one to visualize as I would potentially either need a buffer large enough to hold the entire file or I could restart the entire transfer from packet one if it happens that more than two packets in a row are skipped. Or some other system to guarantee we get all the packets.
Just seems like a lot of memory to keep in ram for every connection on the computer. At this point I am assuming 200-300 people physically connected (er sending to a certain port) to any server at a time if I get lucky.
I''m definitely going to go UDP with this. Exactly how I dunno yet. I still haven''t found much useful stuff on IOCP. I''ll be writting my on guarantee system on top of UDP for when I need it. I''m just trying to figure out how all of these connections (well not exactly connected with UDP but you know what I mean)are managed.
If I have 300 clients talking to a server with UDP then each packet will have 1 of 300 unique name identifiers with it. MAP works well here for locating the buffer any given packet belongs to. It also makes it easy to send system wide messages as I just cycle through the map keys sending whatever I need to them all.
300 clients doesn''t seem like too many to handle as long as the info sent is kept to a minimum. So my whole process would be something like this if I am correct.
Server binds and listens on a certain port.
Client binds and listens on it''s port.
No real connections are made, it''s simply a matter of client sends a packet request to server who then accepts or not. Now the client has permission to trade info with the server. Server simply moniters to see if any incoming info is available. if so then I grab the packet, see who it came from and stick it into the correct place. If I have 300 clients then i can potentially have 300 packets waiting to be received every time the program loops so what do I o, call recv() until nothing else is there? Call it once per loop? A certain number of times? Just really confusing once you break away from a single client and server.
I assume this has to take into account the actual game loop unless the send and recv is done in it''s own thread and the game loop simply does what it does with any information that might be in a TOBEPROCESSED buffer.
Maybe I''m just confusing this more than it has to be.Sorry for such longwindedness here. Just a lot of stuff I''m not clear on yet.
Thanks,
Webby
)