Jump to content
  • Advertisement
  • entries
    503
  • comments
    1888
  • views
    334880

'Frag' files now live on production

Sign in to follow this  
EDI

367 views

Greetings All,


So I pushed ahead last night and implemented production-server delivery of fragments of monolithic resource (.frag) files.

As designed the implementation was very simple, merely uploading the required frag files, changing their permissions, and writing a new function into the Archon (our custom user account system) CGI to process requests for frag files.

//PHP server code for requestion part of a frag fileelse if($cmd=="readFragFile"){ $path=$args['path']; $x=$args['x']; $y=$args['y']; //todo: here is where we will decide if this user has the rights to get this content //this is also where we might lightly transform the content to be keyed against this user //and their session; creating a one-time piece of data that is 'less useful' for redistribution $f=fopen($path,"r"); if($f){ $fileCount=readBinary($f, "V"); $half=floor(sqrt($fileCount)); $index=$y*$half+$x; if($index>=0 && $index<$fileCount){ fseek($f, $index*8, SEEK_CUR); $offset=readBinary($f, "V"); $size=readBinary($f, "V"); fseek($f, $offset, SEEK_CUR); $ret['data']=fread($f,$size); }else{ $ret['error']="Argument out of range."; } fclose($f); }else{ $ret['error']="Unable to open file for reading"; }}
Simple use tests found this code to be very fast, perhaps even a bit faster that serving induvidual files directly; my only explanation for that might be reduction of overhead in seeking a file that hadn't recently been opened.


As a content control measure

You may have noticed the comment in the code, where I will eventually check the on-server user session for authorization. This allows me to specify that various content, stored in frag files will only be served to users that own certain keys.

In addition I can also employ methods to make the data more suitable for single-session-use; in case some group seeks to 'rip' the data and set up a 'pirate' server, that could be accessed via a simple dns-rewrite.

Thankfully these attacks (if they come at all) are more sophisticated than most people will endeavour; most importantly simply having some server verrification stops the far more likely client-side browser hack via runtime JS injection (which is easily copy-pasted or even done by more interesting methods) that frequent gamers might be familiar with.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!