|
Grognot -> RE: Probe the idea of "Poor man's TCP/IP" (2/6/2008 12:06:49 AM)
|
The names of PBM turn files encode the game name in them, as well as year, month, phase and player.
The battle files encode game name, location, and a number I haven't bothered determining the meaning of. I also haven't experimented with determining whether it's harmful to have somebody else's battle files, or to share them.
Backup saved games encode the game name and which player they belong to, but their filenames do not include month/year/phase. Backup saved files already incorporate all .pbm data prior to their generation, as far as I can tell.
The required functionality on the server side would essentially be shared file transfer capability, probably with ZIP compression (commonly available in library form; useful for detecting random corruption as well as saving bandwidth; doable on-the-fly); and with some function for purging old files. A 'request' might be
(a) given a date (of last sync, perhaps in GMT...) and game name --
(1) identify all .PBM and .battle files after that date
(2) if any, zip and provide
(b) given a game name and incoming data that matches the ZIP format,
(1) unpack that archive
(2) if it's valid (not obvious corrupt) keep .pbm and battle files
A client could be written that would facilitate such requests.
This completely ignores multiple facets such as backup save files, any risks of propagating extra .battle files or purging old files. Other than the .zip file bit, it's close to a subset of functionality of, say, rsync or version-control software like CVS.
With a shared CVS or RCS (or Subversion or whatever) repository, you'd just need batch files for getting new files, unzip if need be, and copying them to commin; and moving files from commout to the repository, zipping if one likes, and committing them to the repository. Deciding when to purge files from the repository would be a little trickier.
|
|
|
|
