Menu ▾ ▴

#12 FlightGear Resource/Distribution Tracker

open
nobody
None
5
2008-01-08
2008-01-08
Anonymous
No

during a multiplayer session it may also be desirable for connecting clients to have the option to automatically download missing resources (i.e. scenery, objects, aircraft). Of course, this should be kept totally separate from the multiplayer server code, but it might make sense to consider providing a central server where clients may request a certain resource -in tarball format- matching a given version/md5sum, and get a response from the server with an HTTP/FTP URL where the data can be obtained from.

Such data could then be locally extracted within the user's home directory and use from there, alternatively users could explicitly provide a globally writable "Cache" directory where such resources may be stored.

This should be a much cleaner and much more efficient approach than having clients download the data from other connected clients.

So, the server would basically only act as a "directory" to track resources and their URLs

Discussion

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-01-10

    Logged In: NO

    this is actually also a good idea to enable multiplayer users to optionally download missing aircraft, so that connecting clients would optionally be required to provide a source URL for the aircraft they are using, including a version, name and description - and hash of the URL including a hash of the file to be downloaded, that way servers could maintain a list of "trusted" URLs and valid hashes for downloaded files, so that it can be ensured that only valid files are downloaded and loaded in fgfs.

    So whenever someone connects to a multiplayer server, the server would be provided with information about the aircraft to be used, and if it's not any of the standard aircraft there could be a URL provided, which other clients may use to download the required resources and extract them to a temporary location, i.e. $HOME/.fgfs/Aircraft, using libcurl.

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-02-24

    Logged In: NO

    something like this would have to mirror (pointers to) parts of the base package and make it accessible in a standardized fashion, so that contents (i.e. aircraft, instruments, scenery models, AI objects and possibly even scenery tiles) can be requested in a standardized way that allows exchange of pointers to individual resources, i.e. via URLs, if the contents themselves are being provided via torrents, this could work rather flawlessly and efficiently. So, individual resources could be addressed using torrent files.

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-03-03

    Logged In: NO

    this is another thing that should remain 100% separate from the actual server code, so that it doesn't unnecessarily interfere with server performance. Such a directory server could easily be hosted at a completely different site, but still provide the required resources (i.e. file/version/md5 -> URL mappings)

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2008-05-21

    Logged In: NO

    while this seems somewhat related to MP, please do indeed keep this SEPARATE - this MUST NOT become part of the current/future protocol.
    It's absolutely unnecessary - this can be a very simple system consisting just of a handful components:

    - mySQL server with a simple table indexing MD5 sum of requested file and URLs of sites hosting the corresponding file (i.e. idx/URL)
    - a simple php script to provide query/response facilities - possibly SOAP based
    - libCURL client

    These three components would be sufficient.

    So, whenever a fgfs client encounters an aircraft/resource it doesn't have installed in its base package, it could go like this:

    1) obtain MD5 sum of corresponding component from server/other client (i.e. based on file data and file name / version)
    2) connect to central resource directory server, i.e. at rsrc.flightgear.org
    3) query php script, using the known MD5sum of the necessary component: http://rsrc.flightgear.org/lookup.php?hash=............
    4) script does the lookup in the DB and responds with a comma separated list of URLs providing the component as tarball/ZIP archive
    5) background process or thread may then process this CSV list and try to download the component
    6) validate file integrity using previously known MD5 sum
    7) extract to temporary location, or user specific aircraft directory under ~/Aircraft
    8) make use of resource

    preferably, this "temporary location" would also be added to some sort of list, so that it can be searched in the future for previously downloaded resources.

    Note that this is indeed fairly simple, provides the necessary functionality in a pretty elegant way, and really doesn't bloat the current/future protocol anymore than necessary. Apart from that, this would also help ensure that all clients in a session may optionally HAVE to make use of the SAME files/data (aircraft resources), this might become more relevant in the future, as cheating considerations may have more weight than at the moment.

    Thus, the FG protocol wouldn't necessarily communicate aircraft (file) names directly, but rather a combination of:
    - plain text name
    - file name
    - version
    - MD5sum

    So that all clients in a session may refer to the same set of files by simply making use of the MD5sum of the tarball.

     

Log in to post a comment.