binary zoo
Welcome, Guest. Please login or register.
Did you miss your activation email?
January 19, 2018, 01:28:44 PM

Login with username, password and session length
Search:     Advanced search
30178 Posts in 1158 Topics by 195 Members
Latest Member: dianeanderson
* Home Help Search Login Register
+  binary zoo
|-+  Game Development
| |-+  General Discussion
| | |-+  Networking-for-game-programmers
Pages: [1] 2 Go Down Print
Author Topic: Networking-for-game-programmers  (Read 4699 times)
Prime_8
1000 XP
*
Offline Offline

Posts: 1438



View Profile WWW
« on: February 25, 2013, 02:01:53 AM »

http://gafferongames.com/networking-for-game-programmers/

i have been digging into this .
seems my quick stab a TCP  was ok but not really what a real-time game needs .
any how great read

( my not be worthy of it's own thread )
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #1 on: February 25, 2013, 08:33:31 AM »

Thats an excellent link Prime.

I took some time to read it, as it covers the basics through to advanced stuff.

Which i found invaluable as i know next to nothing about net multiplayer programming.

Thanks for posting.   Cheesy

TMC
Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13185



View Profile WWW Email
« Reply #2 on: February 25, 2013, 02:04:37 PM »

Nice link Prime.  That explains all the technical stuff I'm not clued up on.

@TMC
Does Blitz not have a library that handles most of this for you automatically or at least in a friendlier manner?  I would imagine it does.

In AGK it essentially boils down to a few simple HostNetwork/JoinNetwork & SendMessage/ReceiveMessage commands although there's a lot more if necessary.

Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #3 on: February 25, 2013, 05:56:47 PM »

Quote
Does Blitz not have a library that handles most of this for you automatically or at least in a friendlier manner?  I would imagine it does.

Yes, Blitzmax does, but not Blitz3d.

Although the commands are there, i've no idea how to use them or what they do.

There are no instructions, tutorials or examples for how to use them with the language itself.

There might be a tutorial on the forums though, i havn't looked.

But the link that Prime posted explains all the theory behind it all.
Which i imagine is essential to know, along with how to use the commands in Blitzmax.

That AGK link you posted shows AGK is well documented.
Blitzmax doesn't have that.
Just the commands.   Tongue

TMC
« Last Edit: February 25, 2013, 06:00:05 PM by T_M_C » Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13185



View Profile WWW Email
« Reply #4 on: February 26, 2013, 07:00:26 PM »

That AGK link you posted shows AGK is well documented.
Blitzmax doesn't have that.
Just the commands.   Tongue
I always assumed Blitz was really well documented and that was why DBPro used to get so much flak for it's documentation?  Plus the Blitz community seems pretty pro-active so at worst I'd have thought they would have created the documentation themselves.


The AGK documentation is more than good enough for anyone with a little coding knowledge IMO, it's just the new coders that seem to struggle with it as there aren't usage examples for every command. 
Logged

Prime_8
1000 XP
*
Offline Offline

Posts: 1438



View Profile WWW
« Reply #5 on: April 02, 2013, 04:57:26 AM »

well after F'n arround with TCP , (its a virtualization of a file stream like interface , with writes and reads to a stream .. and the idea of a connection is simulated . )   i find out TCP is built ontop of UDP .

all of what makes TCP cool and feel like reading and writing to stream or ram is all just virtualized . LOL

so why waste my tim ein TCP land if i know UDP can be faster and better for games .. heheh ..

many  weeks of tinkering  and some great help from Aaron ovre on Ember , i have been hammering a UDP system out to do what a game needs . i will decid eif i make it a plugin / dll  kit or not later ..

where im at ..

 I can:

   * Effect a NAT punch through (jump is a better word IMO )  ( needed for plain UDP )
   * Emulate or simulate connections in a connection-less system.
   * Light security :
             has a unique protocol ID a u16 , that all pakets must have to even be looked at .
             size is watched , if too big the packet is not even looked at ( no buffer overrun issues ).
             packet header format is precise and has some bit packed UNIONS  and if they do not match the packet is rejected .
             users who join from behind the same router or  share same public IP , are identified by a hidden key on connection making it very hard for an other player in same IP to spoof being them  .
             packets have a time code & sr# , and a priority , and type .
            under the hood i pass the data block of the packets to func *ptr fore each typ , with the last type being user supplied func *ptr . so users can read USER_TYPE packet data after the header  

   * Serve / Host to multiple clients without much bother

   * ! Interface more than one host making spider web like networking possible . (pic 5 )
         that is more than one server can be in to pool of connected clients acting as co hosts or relays (not really good for games but cool :: ahem: file sharing systems .. heheh )

   * Servers and hosts don't freak out or drop if a virtual connection is deemed lost , or an actual client 'rudely' disconnects or drops without warning .

   ** the last 2 point make this possible , ability to throw the hosting chore around the clients , like how the dealer job moves around when playing poker


  * command scan be set in the message entry box :
 \ip:port  << sets address to connect , supports ipv4 & ipv6  
 \server  << sets self to manage connections like a server / host or return to just client mode
 \bing     << makes other users see a BING! text on their chet display and plays a bing.ogg file/sound
 \alias:nameyouwantstring  << sends a alias you want to be see as to server and server can propagate that out to others
 \verbose << toggles how much / if any debug gets written to the sys console  
 \hidecon  << hides the sys console window
 \showcon << shows sys console and makes verbose == true .

 some server function pending like :
 \ban:ip:min  << blocks all incomming form that IP  for X min  
 \permaban:ip << locks that ip and put it in a ini file and is auto applied on relaunch
 \relay:ip:port << all incoming packets are pure relayed to this addy' using existing filtering rules for the app .

it has not been optimized , but will be  , still its damn fast and stable.  

PS teh wee number on the right of the window name in each window is the mean RTT or round trip time .
RTT includes time it to to compose packet , send it , decode at other end , time for the other end to compose a Ack packet and send it back , and have the Ack packet decoded and ID & SR# check  in milliseconds. LOL or long ping.
value ==  ( value + thisRTT )/2 ; // so it is a light rolling mean .


* RP_UDP_5.jpg (99.32 KB, 756x277 - viewed 299 times.)

* mchat_6.jpg (304.87 KB, 791x708 - viewed 319 times.)
« Last Edit: April 02, 2013, 05:15:35 AM by Prime_8 » Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #6 on: April 02, 2013, 10:26:10 AM »

Thats really interesting Prime.

Looks like you're making some good progress.

TMC
Logged
Prime_8
1000 XP
*
Offline Offline

Posts: 1438



View Profile WWW
« Reply #7 on: April 03, 2013, 09:14:13 AM »


got user dropping management sorted ..

Spoiler (click to show/hide)

ok drops are now managed and the the server mode will not send to a connection in dropped status ..  until it hears from it again .

when a new ip&port conencts it will quickly see if that new address set  is containing a matching ID# and key value to a existing connection , if it does it will edit that CX's address ,and set connected == true ..

this is handy if a player/client has a wonky internet connection or a router / firewall issue that causes come port rolling  , this causes its CXthrouble_counter++ .
if CXthrouble_counter > MAX_CX_TRUBLES , then  connected =false, and blocked = true .
this effectively blocks the ID & key  combo .

if too many MAX_CX_TRUBLES comes form one IP , ie teh player launches a new client each time they hit MAX_CX_TRUBLES , the server will add their IP to the ignore list to BAN_TIME (99min default )
if the user keeps trying to connect during the ban bore than 20 times , the server puts them in the perma-ban list .
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #8 on: April 03, 2013, 09:59:18 AM »

Cool.

I know who to come to now if i ever get into coding my own multi player system.  Wink

TMC
Logged
Prime_8
1000 XP
*
Offline Offline

Posts: 1438



View Profile WWW
« Reply #9 on: April 04, 2013, 03:50:59 AM »

LOL , NP
Logged

Prime_8
1000 XP
*
Offline Offline

Posts: 1438



View Profile WWW
« Reply #10 on: April 05, 2013, 01:29:49 AM »

ok the computer at work has too much of a firewall. 10*lag

here is it on my home rig , slider packets on loopback 2 to 3 ms low end to 15ms on the high lag end.


* mchatms1.jpg (221.56 KB, 676x698 - viewed 307 times.)
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #11 on: April 05, 2013, 09:49:02 AM »

Good stuff.  Smiley

TMC
Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13185



View Profile WWW Email
« Reply #12 on: April 05, 2013, 03:02:32 PM »

Good stuff.  Smiley
I agree....even if I don't understand some of it  Grin
Logged

Prime_8
1000 XP
*
Offline Offline

Posts: 1438



View Profile WWW
« Reply #13 on: April 15, 2013, 09:30:01 AM »

seems i had a bug in the server client hand off to new server .

 I had made an assumption regarding Nat and connection .

here is the bottom line .

PC exposed / public ports :
 Can send packets out at target IP:port
 Can be a server , because it will actually recite incoming packets , solicited or not .
  >> can see the real public port your Nat client is routing your coms though for THIS conenction.

PC behind a decent / average NAT , no exposed ports .
 Can send packets out at target IP:port
 Can ONLY receive packets from remot PC that send back your your PUBLIC port your NAT chose / rolled to.
 >> can see the real public port of any PC that sent it a message that made it to your APP .    

SO

server <> client[] ;// no probs for server with public ports or port forwarding in the router and open on your firewall .

server <> client[] ;
----------<>server[] ; // no problem because those servers are actually just clients to your server  

so the sticky parts:

how can client[4] talk directly to client[12]  , i mean server can send client[all] each others ip:publicPort  
so they know how/where to message each other ..  but if  each client just sents to an other ip:publicport , that packet will be rejected .


both clients must have attempted to reach each others public port 1 time before a real packet will get through .  I don;t knopw the real tech name for this , but i call it Knocking on the door .

once teh two clients have knocked on each others door , their respective NATs  will permit direct peer<>peer comms .

so how can we pass the job of server to a a given client ?

well its not simple but it's not hard .

current public server passes a roster packet, that has new server target bit set next to one of the clients in the roster .

the client who is the new server , see teh server bit next to self in the roster , & its own public IP:port comebo
(it's the only way your app can know it's true NAT negotiated public IP )
 new server then sends a knock to each of the other client in the roster doors . ( most will never get the knock ) This tells this server's NAT expect incoming traffic back form the IP:Port(s) it just knocked on . ( misnomer as its more like creating temp mail boxes for them )

now a 10 sec ( pretty standard with current NAT's code / settings ) window in witch knocks coming in from the clients will lock onto thier 'mail boxes' .

at the same time the new server was knocking on client doors. they were all knocking on the new server's door .

if the remote knock was done before the new server knocked , the the server 's knock created the punch-through , conversely if the server's knock got to the client's door fist then , the clients knock creates that punch-through .

either way it makes no diff the order , as long as each client  knocks on server and server knocks on each client .

now the new server must send heartbeat packets to the clients to hold those punch-throughs open

then as each client gets a unique key form new server & passes a test key and echos it to first server , the first server send confirm packet to new server , and first server stops sending heart beats to that client .

once the first server has no clients left but the new server to send heart beats to it will send a polite disconnecting packet .

once original server disconnects from the new server , the new server is own managing all the connected clients , sending heart beats and checking for responses .

org server may stay available as a fall back in-case of connection troubles , like a lobby or such but after about 10 sec it will no longer be able to reach the new server unless the new server still sends a heart beat to the org' server about every 5 sec at most .


it's easy to get confused , because we are setting over or around a layer of security built into your PC's fire wall .

it take time for your router to roll your external port and do a re forward , same again if you PC's fire wall is doing same .

fastest speed / lowest lagg is only possible with router port forwarding and opening those ports on you PC's firewall(s) . ( that also kills NAT on those ports and effectively make them public .

TCP and UDP  suffer this .
but UDP is more forgiving of this system while it is setting up and should a user drop . ( IMO )



« Last Edit: April 15, 2013, 09:32:53 AM by Prime_8 » Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #14 on: April 15, 2013, 09:54:04 AM »

Woa.

Thats way over my head.   Shocked

Interesting read nonetheless.

TMC
Logged
Pages: [1] 2 Go Up Print 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines
Simple Audio Video Embedder
Valid XHTML 1.0! Valid CSS!