Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Mar 2003
Offline Last Active Oct 11 2016 10:27 AM

Posts I've Made

In Topic: Understanding Peer 2 Peer

21 May 2016 - 02:29 PM

You just need better authentication / encryption.


Basically, never work with raw sockets and IP addresses directly, if you can avoid. Negotiate P2P secure connections, preferably via a secure server, which can also help with the NAT punch-through and packet reflection. 


Even then, don't trust the data send by clients. But it's more about game hacks and exploits, and how your game handles cheating, rather than a straight-up security issue.


Roughly how it looks in APIs such as XBox Live, PSN ...


1) player A creates a game session. That game session then resides on a secure server. 


2) player A registers himself with the game session (probably part of the game session creation process anyway).


3) all communications between game server and player A are uniquely encrypted and secure.


4) player B searches for the game session.


5) player B finds the game session, then registers himself with the game session.


6) all communications between game server and player B are uniquely encrypted and secure.


7) player A gets notified by the game server that player B is registered with the game session. Received security information on how to connect to player B.


8) player B gets notified by the game server that player A is registered with the game session. Received security information on how to connect to player A.


9) Player A, or player B, or both then attempt to connect to each other. Their communications will be encrypted, and only decipherable by them (ideally). 


and so on...


The game layer sees secure addresses being established under the hood, with payloads coming in. The game code doesn't really deal with raw IP's any more (on steam, it's just player Steam Ids). Which makes it a little bit tricky as far as debugging is concerned, but hey.

In Topic: i keep buying games and they're not what i expected

18 May 2016 - 02:51 AM

BTW, The Wicher 3 is on sale on Steam right now (at least UK), £18. Well worth the price. 

In Topic: The first video game enemy you ever murder.

10 April 2016 - 04:07 AM

We all played games, we all murder stuff. I'm willing to bet that every member on this site have a video game body count of at least over 1000.

I have 20,104 notches on my minigun that say you're way off the target.

In Topic: And the Best President for America is…

10 April 2016 - 03:53 AM

As if a person's character has no bearing on their behaviour and, when in a position of power, has no influence on the amount of damage they can inflict.

Recent history shows just that. And why people pay attention to what the guy who will be supposedly in charge says.

Long gone are the days when voting equated to selecting between John Jackson and Jack Johnson.

I guess now it's more between John Jackson and Mecha-Nixon, and I wish all the best to Bernie. I hope his bureaucrat sex-appeal and sensible fiscal policies swoon the electorate.

Enough with demagogues and plutocrats! Feel the Bern 2016! Yay? Who's with me?!?

In Topic: Syncing Client/Server

08 April 2016 - 12:52 PM

A coarser grain is detrimental. After all, you need to send those 'bitfield headers'.

Assuming you do delta on single bytes, for the sake or argument, the gain will only 1/8th compression at best.

A vector is usually atomic. One component changes, it's safe to assume the other components also changed to some degree as well.

If you run into long lengths of bitfield headers (lots of little components changing all over the place), it can mean you need to optimise those components in groups based on their frequency and times of change. Thus reducing the header size, and the frequency of delta transmissions.

You can even write meta-data statistics about it, and estimate how you could improve your traffic by bundling up components more efficiently.

Something i actually experimented with before. The delta-encoding was on fixed-lenght byte buffers.

I run a crude statistical analysis on the frequency of byte changes. I remapped the byte order in order of frequency of change. That gave me runs of contiguous bytes that would change and not change at roughly the same time. The static data that never changed, for example, up front.

Then I ran a simple RLE to build up my delta packets. That gave quite a decent compression. Not optimum as more application-aware delta-compression algorithm, but hey.