here''s my idea for the networking aspect of a 3rd-person online game thingy: Server: one main TCP (blocking) socket (does accept()ing) one main UDP socket (does recvfrom()ing) for each client, there is a TCP (blocking) socket this socket is used for must-arrive messages like addplayer, drop player, fire (more on this l8er), chat msgs), these msgs arent gonna need to be low-lag msgs, so it wont matter if they get delayed a second or so for each client, their SOCKADDR is stored with the SOCKADDR, the main UDP socket will send them updates on player positions and the like, anything that will be happening fast and often and doesnt matter if you lose some packets here and there Threads on server: main thread takes care of UDP socket stuff, sends to TCP sockets when required secondary thread uses blocking TCP socket(s) and the select() function to get must-recieve msgs from players (and reply if required) Client: one main TCP (blocking) socket used to conect to server & do handshake and whatever else (sending name, etc), also for recv()ing must-get-there messages like addplayer, etc.... one main UDP socket used to send non-must-get-there messages, like positional updates Threads on Client: main thread --> does graphics, input, etc... (all normal game stuff), sends positional updates thru UDP socket when necessary secondary thread --> uses blocking TCP socket to talk w/ server, get must-get stuff tertiary thread --> uses blocking UDP socket to talk w/ server, get pos updates, wutever ---------When gun is fired by clientA:------------- clientA sends "FIRE" message thru UDP socket, with a certain FireID (all packets have sent w/ them an ID#, unique for each client, but different each time the client logs on, anyway....) clientA also sends "FIRE" message thru TCP socket, with the same FireID Scenario 1 -> "FIRE" message is recieved by the server over the UDP socket server adds that FireId to a list of FireId''s its gotten from UDP sockets server does same thing as client, but sends to all other clients on their UDP & TCP sockets server later recieves the TCP packet, checks to see if its FireID is in the list its already sent out, it is, so dont send it out (it would be the 2nd time) Scenario 2 -> "FIRE" message is NOT recieved by the server over the UDP socket server recieves the TCP packet, checks to see if its FireID is in the list its already sent out, it is NOT, so server does same thing as client, but sends "FIRE" message to all other clients on their UDP & TCP sockets Well, after all that reading, do my ideas sound good? professional? hideous? Respond w/ any suggestions or whatever <the> MadProgrammer

waste of bandwidth, you NEVER send the data more then it needs to be sent. if the message MUST be sent then use TCP if its ok to be dropped then use UDP. simple as that.

you do realize that fire commands dont need to be sent on a tcp line since dropped packets normally dont happen too often (if it does then the player should be on another server). only thing that really needs to be sent via TCP are have to get messages that if dropped could compltly disrupt game nor could ever be extrapolated. things like chat messages, player adds/drops, server commands like changemap, rcon stuff, etc.

also dont use unique ids, alone, also the client ip:port pair.

UDP isnt that unreliable that you have to mirror it with TCP. Build a rudimentiarty almost-relaible UDP scheme (1 resend on unacknoledge packets) should be sufficient. If you absolutely must have reliable streams, use TCP then, that''s what it''s made for.

Good Luck!

-ddn

UDP isnt that unreliable that you have to mirror it with TCP. Build a rudimentiarty almost-relaible UDP scheme (1 resend on unacknoledge packets) should be sufficient. If you absolutely must have reliable streams, use TCP then, that''s what it''s made for.

Good Luck!

-ddn

If you''re going to build a semi-reliable layer on top of UDP, why not go all the way and make a reliable layer also. You could have 3 settings when sending, one is unreliable, one is a single resend on no ack, the other is resend until ack.

If you''re going to build a semi-reliable layer on top of UDP, why not go all the way and make a reliable layer also. You could have 3 settings when sending, one is unreliable, one is a single resend on no ack, the other is resend until ack.

i was trying to get away from making my own reliability thingy, because of the overhead i thought would be required.

also, is it really that bad to resend a 15 byte packet? this firing thing is going to be like rocket launchers and the like, so if someone doesnt see it firing, it could change a lot.

also, it does have to get there, as stated above, but it also needs to get there ASAP. therefore, i send it over UDP w/ hopes it will arive, and then by TCP just in case it doesnt

MadProgrammer, you''re not going to see any speed or responsiveness increase by mirroring your UDP packets in TCP. You''re just adding _more_ overhead for the same result. You''re using more bandwidth: TCP packets going to the same address will slow down your UDP packets somewhat. You''re using an extra file descriptor for the extra reads/writes. You''re using extra CPU time on your server processing incoming messages twice.

People use UDP because they don''t _need_ the guaranteed delivery and packet ordering that TCP promises. (That''s another thing to think about. What happens when you get the same UDP packet twice, even though it was sent once. Or UDP packets arrive out of sequence. That can also happen under UDP.)

If you decide you want these features of TCP, just use TCP. The writers of your TCP stack knew what they were doing, so there''s a good chance it''ll be faster than a hackneyed double UDP-TCP scheme.

UDP is good for things like streaming video, since you won''t notice a dropped frame. It''s good for games that send state info rather than events. (Absolute locations, not things like ''I''m moving forward now'', ''I''m firing a rocket now''.)

Since you seem to be sending events that you need guaranteeded, stick with TCP.