'Frag' files now live on production

posted in A Keyboard and the Truth for project 96 Mill
Published December 13, 2013
Advertisement
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.
1 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement