539
edits
Nl/Terrasync: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 18: | Line 18: | ||
== Nieuws == | == Nieuws == | ||
Terrasync is begonnen als een op zichzelf staand rsync-gebaseerd hulpprogramma. Er lijken echter geen goede/robuuste multiplatform bibliotheken beschikbaar te zijn voor ons gebruik. We wilden terrasync direct in de kerncode inbouwen, zodat we het downloaden van tegels ( | Terrasync is begonnen als een op zichzelf staand rsync-gebaseerd hulpprogramma. Er lijken echter geen goede/robuuste multiplatform bibliotheken beschikbaar te zijn voor ons gebruik. We wilden terrasync direct in de kerncode inbouwen, zodat we het downloaden van tegels (Engels=tiles) beter konden sturen en deze vervolgens direct in de sim laden (versus heeft soms geen zichtbaar gevolg in tegels of een gedeeltelijke vulling van tegels als een extern gereedschap rsync liep). | ||
Zoals sommigen van u waarschijnlijk hebben gemerkt, zijn er ontwikkelingen in de terrasync hoek op het gebied van codering, meestal door James en soms door Torsten. De belangrijkste reden is het protocol om landschap te distribueren nuiet meer via SVN te laten plaatsvinden, maar gemakkelijker te implementeren protocollen in te zetten. Het idee is om HTTP te gebruiken als middel om de bestanden te downloaden die terrasync nodig heeft. Dit zou het veel gemakkelijker moeten maken voor "hosts" om een "mirror" in te zetten, het maakt het waarschijnlijk ook mogelijk om een CDN te gebruiken voor load balancing met positieve gevolgen voor de "client". | |||
De bedoeling is om, zodra 2016.1 is uitgebracht, over te stappen op HTTP voor TerraSync (in plaats van SVN), omdat dit veel meer mogelijkheden geeft om de code te verspreiden. De cache bestanden zijn klein en weerspiegelen de revisie van elk bestand in de lokale map; ze zijn vergelijkbaar met de gegevens die een echte SVN client opslaat in zijn svn' directory in de root-file. Ik verwacht dat de zuivere HTTP-oplossing enkele gelijkaardige bestanden nodig heeft om de HTTP cache-blokken van bestanden die het downloadt op te slaan - één bestand in de hoofdmap van de structuur of per directory. (Er zijn voordelen en nadelen voor beide.) | |||
* ondersteuning van de verschillende mogelijkheden in de code zou heel alstig worden, dus de intentie is om alleen de HTTP-methode direct in FlightGear te ondersteunen, ook bekend als 'ingebouwde terrasync' | |||
* Een van de belangrijkste voordelen van het HTTP-systeem is dat het SHA1 hashes gebruikt in plaats van SVN revisies om bestanden te identificeren, en er wordt geen (server) URL opgeslagen in de gedownloade directories. Dit betekent dat u een terrasync directory kunt opzetten met bestanden die worden gedownload door elk mechanisme dat u wilt (DVD, BitTorrent, kopiëren vanuit een andere computer) en mits de SHA1 hashes overeenkomen, zullen de bestanden niet opnieuw worden gedownload. Bestanden die verouderd zijn, worden vernieuwd, maar alleen die bestanden. Dit betekent dat overschakelen van SVN -> HTTP ervoor zorgt dat nietdownloaden alles weer opnieuw wordt gedonload. | |||
Het overschakelen naar een andere server, zelfs binnen dezelfde FG-sessie, is ook mogelijk en zorgt er ook nu voor dat niet alle eerdere bestanden opnieuw moeten worden gdownload, in tegenstelling tot de SVN-opzet waarbij de server-URL deel uitmaakt van de repositorystructuur. | |||
* het terrasync /netwerkprotocol/ zal blijven, wat betekent dat u uw eigen externe terrasync systeem kunt schrijven (met gebruik van een breed scala van computertalen, waaronder Python) met behulp van rsync of elk ander mechanisme dat u maar wilt. Mijn hoop is dat dit een goed en onderhoudbaar uitgangspunt biedt voor zeer gevorderde gebruikers, terwijl het ingebouwde HTTP mechanisme eenvoudig en robuust zal zijn (dankzij het feit dat het op hash gebaseerd is) voor 95% van de gebruikers. | |||
We hebben al drie kopieen van het complete landschap online, één bij sourceforge en twee bij private servers. De sourceforge computer ontvangt dagelijks updates van de belangrijkste scenery van http://scenery.flightgear.org/ en alle andere mirrors (computers) halen hun gegevens van de sourceforge server. We besloten de vorige methode, om de klant te vertellen over de dichtstbijzijnde mirror, te laten vallen en in plaats daarvan een webservice (http://scenery.flightgear.org/svn-server) te bevragen ten gunste van het gebruik van een stabielere serviceprovider van het internet: het domeinnaamservice (DNS) systeem. | |||
== Related content == | |||
* Howto: Install scenery | |||
* TerraMaster | |||
== Footnotes == | |||
Jump up ↑ Torsten Dreyer (May 12th, 2016). Re: [Flightgear-devel] Enable terrasync/http by default . | |||
Jump up ↑ Torsten Dreyer (May 11th, 2016). [Flightgear-devel] Clone the HTTP scenery data with terrasync.py . | |||
Jump up ↑ In FGRun, this can be done via the appropriate checkbox on the last page. In FFGo, just uncomment the --enable-terrasync option from the default configuration in the Options Window (the “big window” on the left, below the aircraft list). | |||
Jump up ↑ As derived from an inspection of the FlightGear 2016.2.0 source code on March 21, 2016. | |||
Jump up ↑ James Turner (May 4th, 2016). Re: [Flightgear-devel] The future of terrasync.rvice (DNS) systeem. | |||