539
edits
Nl/Terrasync: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{BeingTranslated}}[[User:Kees|Kees]] ([[User talk:Kees|talk]]) 15:01, 12 December 2017 (EST) | {{BeingTranslated}}[[User:Kees|Kees]] ([[User talk:Kees|talk]]) 15:01, 12 December 2017 (EST) | ||
''Terrasync moet niet worden verward met [[TerraGear]], een gereedschap om [[Scenery]] (landschap) te genereren.'' | |||
''Terrasync moet niet worden verward met TerraGear, een gereedschap om | |||
Om het terrein onder je vliegtuig te kunnen zien, moet je het betreffende "landschap" installeren. Dit kan gebeuren door bepaalde stukken "landschap" te downloaden voordat je gaat vliegen zoals beschreven in het artikel scenery installeren. | Om het terrein onder je vliegtuig te kunnen zien, moet je het betreffende "landschap" installeren. Dit kan gebeuren door bepaalde stukken "landschap" te downloaden voordat je gaat vliegen zoals beschreven in het artikel scenery installeren. | ||
| Line 8: | Line 7: | ||
Als je een stabiele en redelijk snelle internetverbinding hebt, kunt je TerraSync gebruiken. Het is een hulpprogramma dat automatisch de nieuwste versie van het benodigde FlightGear-landschap downloadt terwijl de simulator draait. TerraSync draait op de achtergrond (optioneel als een afzonderlijk proces), bewaakt jouw positie en downloadt (of actualiseert) het nieuwste landschap van de master scenery server "just in time". | Als je een stabiele en redelijk snelle internetverbinding hebt, kunt je TerraSync gebruiken. Het is een hulpprogramma dat automatisch de nieuwste versie van het benodigde FlightGear-landschap downloadt terwijl de simulator draait. TerraSync draait op de achtergrond (optioneel als een afzonderlijk proces), bewaakt jouw positie en downloadt (of actualiseert) het nieuwste landschap van de master scenery server "just in time". | ||
De master repository voor TerraSync, de online bron van waaruit TerraSync zijn bestanden downloadt, wordt één keer per dag gesynchroniseerd met de FlightGear Scenery Database. Dus als je TerraSync gebruikt, zult je altijd beschikken over | De master repository voor TerraSync, de online bron van waaruit TerraSync zijn bestanden downloadt, wordt één keer per dag gesynchroniseerd met de [[FlightGear Scenery Database]]. Dus als je TerraSync gebruikt, zult je altijd beschikken over | ||
# de nieuwste stg | # de nieuwste [[File_Formats#.2A.stg]], die FlightGear vertellen waar een object moet worden geplaatst. | ||
# de nieuwste statische modellen voor objecten. (Statische modellen geven unieke objecten weer die slechts op één plaats bestaan, zoals beroemde gebouwen of monumenten.) | # de nieuwste statische modellen voor objecten. (Statische modellen geven unieke objecten weer die slechts op één plaats bestaan, zoals beroemde gebouwen of monumenten.) | ||
# de nieuwste gemeenschappelijke modellen voor objecten. (Generieke modellen die meer dan eens op verschillende plaatsen worden gebruikt, kunnen verschillende objecten vertegenwoordigen, zoals generieke huizen of schepen) | # de nieuwste gemeenschappelijke modellen voor objecten. (Generieke modellen die meer dan eens op verschillende plaatsen worden gebruikt, kunnen verschillende objecten vertegenwoordigen, zoals generieke huizen of schepen) | ||
== Aankondiging == | == Aankondiging == | ||
In het verlengde van FSweekend gaan we een aantal ideeën testen hoe we osm2city landschap met terrasync kunnen verspreiden. Als eerste stap heb ik net een map toegevoegd met als titel Objects_1 waarin de gebouwen van osm2city voor e005n46 tot e010n48. Mensen die de fgfs geïntegreerde terrasync gebruiken zullen (nog) geen verschil opmerken. Bij het gebruik van terrasync. py moet je merken dat bestanden in die mappen worden gedownload, maar ze verschijnen (nog) niet in het landschap. Waarschijnlijk gooien we sommige of alle bestanden in die directory weg zonder voorafgaande kennisgeving, dus vertrouw er niet op en maak geen back-upkopieën. Torsten | In het verlengde van FSweekend gaan we een aantal ideeën testen hoe we osm2city landschap met terrasync kunnen verspreiden. Als eerste stap heb ik net een map toegevoegd met als titel Objects_1 waarin de gebouwen van osm2city voor e005n46 tot e010n48. Mensen die de fgfs geïntegreerde terrasync gebruiken zullen (nog) geen verschil opmerken. Bij het gebruik van terrasync. py moet je merken dat bestanden in die mappen worden gedownload, maar ze verschijnen (nog) niet in het landschap. Waarschijnlijk gooien we sommige of alle bestanden in die directory weg zonder voorafgaande kennisgeving, dus vertrouw er niet op en maak geen back-upkopieën. Torsten <ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/35476181/ | |||
|title = <nowiki> [Flightgear-devel] ATTN: terrasync changes </nowiki> | |||
|author = <nowiki> Torsten Dreyer </nowiki> | |||
|date = Nov 7th, 2016 | |||
|added = Nov 7th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
== 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 (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). | 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). <ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/35061363/ | |||
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki> | |||
|author = <nowiki>Curtis Olson</nowiki> | |||
|date = May 3rd, 2016 | |||
|added = May 4th, 2016 | |||
|script_version = 0.31 | |||
}} | |||
</ref> | |||
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". | 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.) | 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.) <ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/34767003/ | |||
|title = <nowiki>Re: [Flightgear-devel] Launcher changes for 3.8</nowiki> | |||
|author = <nowiki>James Turner</nowiki> | |||
|date = Jan 14th, 2016 | |||
|added = May 4th, 2016 | |||
|script_version = 0.31 | |||
}} | |||
</ref> | |||
* 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' | * 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' | ||
| Line 29: | Line 51: | ||
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 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. | * 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. <ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/35064352/ | |||
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki> | |||
|author = <nowiki>James Turner</nowiki> | |||
|date = May 4th, 2016 | |||
|added = May 4th, 2016 | |||
|script_version = 0.31 | |||
}} | |||
</ref> | |||
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. De fgfs client zal een resource record (RR) type NAPTR (network authority pointerhttps://en.wikipedia.org/wiki/NAPTR_record) bevragen voor de dns naam terrasync.flightgear.org en de gegevens analyseren om de beste terrasync mirror te vinden. Deze gegevens zijn al geconfigureerd en kunnen hier worden bekeken: https://toolbox.googleapps.com/apps/dig/#ANY/terrasync.flightgear.org. | 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. De fgfs client zal een resource record (RR) type NAPTR (network authority pointerhttps://en.wikipedia.org/wiki/NAPTR_record) bevragen voor de dns naam terrasync.flightgear.org en de gegevens analyseren om de beste terrasync mirror te vinden. Deze gegevens zijn al geconfigureerd en kunnen hier worden bekeken: https://toolbox.googleapps.com/apps/dig/#ANY/terrasync.flightgear.org. | ||
Deze techniek zou ons in staat moeten stellen om veschillende scenery's aan te bieden, uiteindelijk zelfs voor delen van de wereld en dat op een manier die beduidend eenvoudiger zal zijn dan bij SVN het geval zou zijn geweest. Het bespaart ook vele gigabytes op de scenery mirror, omdat niet alle 50.000+ beschikbare revisies continue beschikbaar hoeven te zijn. Ik zal de komende dagen beginnen met het toevoegen van de vereiste code zodat de nieuwe opzet hopelijk voor de 2016.2 release gereed zal zijn. Ik zal een bericht zenden wanneer ik de schakelaar omzet om de nieuwe versie van terrasync in te schakelen. In de tussentijd ziet u mogelijk een aantal "build"fouten of andere hickups van het systeem. Ik beloof u dat ik die fouten zo snel mogelijk op zal lossen. Als u terrafs gebruikt, ontvangt u al uw gegevens van de nieuwe http mirror, hoewel u geen gebruik maakt van de DNS-dienst resolver.http:// | Deze techniek zou ons in staat moeten stellen om veschillende scenery's aan te bieden, uiteindelijk zelfs voor delen van de wereld en dat op een manier die beduidend eenvoudiger zal zijn dan bij SVN het geval zou zijn geweest. Het bespaart ook vele gigabytes op de scenery mirror, omdat niet alle 50.000+ beschikbare revisies continue beschikbaar hoeven te zijn. Ik zal de komende dagen beginnen met het toevoegen van de vereiste code zodat de nieuwe opzet hopelijk voor de 2016.2 release gereed zal zijn. Ik zal een bericht zenden wanneer ik de schakelaar omzet om de nieuwe versie van terrasync in te schakelen. In de tussentijd ziet u mogelijk een aantal "build"fouten of andere hickups van het systeem. Ik beloof u dat ik die fouten zo snel mogelijk op zal lossen. Als u terrafs gebruikt, ontvangt u al uw gegevens van de nieuwe http mirror, hoewel u geen gebruik maakt van de DNS-dienst resolver. <ref>{{cite web | ||
|url = http://sourceforge.net/p/flightgear/mailman/message/35057670/ | |||
|title = <nowiki>[Flightgear-devel] The future of terrasync</nowiki> | |||
|author = <nowiki>Torsten Dreyer</nowiki> | |||
|date = May 2nd, 2016 | |||
|added = May 2nd, 2016 | |||
|script_version = 0.28 | |||
}} | |||
</ref> | |||
De http download methode zal goeddeels op dezelfde manier werken als voorheen, maar nu worden alleen de (eventuele) gewijzigde bestanden gedownload. De svn methode vereist 2x de werkelijke ruimte op de harde schijf als gevolg van de manier waarop svn werkt. Gewoonlijk vereist Git dat je elke versie die ooit is gemaakt downloadt om de nieuwste kopie te krijgen (er zijn werk omwegen voor het geval je gewoon de meest recente versie wilt.) Dus het eindresultaat voor de gemiddelde gebruiker die gewoon wil downloaden om de scenery te gebruiken is dat de http methode in het algemeen sneller en eenvoudiger zal zijn. Het vereenvoudigt ook de code binnen FlightGear behoorlijk en moet de synchronisatie robuuster maken. Zoals eerder gezegd, moet het de taak vereenvoudigen om een scenery mirror op te zetten voor degenen die dat willen. Net als voorheen hebben power users meerdere opties voor het updaten van scenery of mixen en samenvoegen met | De http download methode zal goeddeels op dezelfde manier werken als voorheen, maar nu worden alleen de (eventuele) gewijzigde bestanden gedownload. De svn methode vereist 2x de werkelijke ruimte op de harde schijf als gevolg van de manier waarop svn werkt. Gewoonlijk vereist Git dat je elke versie die ooit is gemaakt downloadt om de nieuwste kopie te krijgen (er zijn werk omwegen voor het geval je gewoon de meest recente versie wilt.) Dus het eindresultaat voor de gemiddelde gebruiker die gewoon wil downloaden om de scenery te gebruiken is dat de http methode in het algemeen sneller en eenvoudiger zal zijn. Het vereenvoudigt ook de code binnen FlightGear behoorlijk en moet de synchronisatie robuuster maken. Zoals eerder gezegd, moet het de taak vereenvoudigen om een scenery mirror op te zetten voor degenen die dat willen. Net als voorheen hebben power users meerdere opties voor het updaten van scenery of mixen en samenvoegen met verschillende bronnen als ze dat willen. <ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/35061856/ | |||
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki> | |||
|author = <nowiki>Curtis Olson</nowiki> | |||
|date = May 4th, 2016 | |||
|added = May 4th, 2016 | |||
|script_version = 0.31 | |||
}} | |||
</ref> | |||
De techniek van de http repository is veel eenvoudiger dan die van de svn repository en het zal vrij eenvoudig zijn om een lokale mirror op te zetten of stukjes data te downloaden. Met enige nog te ontwikkelen scriptcode (python bijvoorbeeld) is het niet nodig om bestaande data opnieuw te downloaden. Ik weet niet hoe terramaster werkt, maar ik weet zeker dat het gemakkelijk zal zijn aan te passen aan de nieuwe http toegangsmethode. | De techniek van de http repository is veel eenvoudiger dan die van de svn repository en het zal vrij eenvoudig zijn om een lokale mirror op te zetten of stukjes data te downloaden. Met enige nog te ontwikkelen scriptcode (python bijvoorbeeld) is het niet nodig om bestaande data opnieuw te downloaden. Ik weet niet hoe terramaster werkt, maar ik weet zeker dat het gemakkelijk zal zijn aan te passen aan de nieuwe http toegangsmethode. <ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/35062543/ | |||
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki> | |||
|author = <nowiki>Torsten Dreyer</nowiki> | |||
|date = May 4th, 2016 | |||
|added = May 4th, 2016 | |||
|script_version = 0.31 | |||
}} | |||
</ref> | |||
Het doel is om SVN volledig af te stoten en alleen nog de HTTP repository te gebruiken. Ik zou dat doel het liest z.s.m. willen bereiken, omdat we op dit moment twee single-points of failure hebben voor de SVN-service. De eerste is de webdienst http://scenery.flightgear.org/svn-service (draait op een private webserver) en de tweede is de enige SVN-server beschikbaar voor publieke toegang, ook gehost op een private server. Als een van beide wegvalt, is de SVN-terrasync dood. Ik heb geleerd dat het een slecht idee is om niet te voorzien in een terugvalmechanisme. | Het doel is om SVN volledig af te stoten en alleen nog de HTTP repository te gebruiken. Ik zou dat doel het liest z.s.m. willen bereiken, omdat we op dit moment twee single-points of failure hebben voor de SVN-service. De eerste is de webdienst http://scenery.flightgear.org/svn-service (draait op een private webserver) en de tweede is de enige SVN-server beschikbaar voor publieke toegang, ook gehost op een private server. Als een van beide wegvalt, is de SVN-terrasync dood. Ik heb geleerd dat het een slecht idee is om niet te voorzien in een terugvalmechanisme. <ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/35062543/ | |||
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki> | |||
|author = <nowiki>Torsten Dreyer</nowiki> | |||
|date = May 4th, 2016 | |||
|added = May 4th, 2016 | |||
|script_version = 0.31 | |||
}} | |||
</ref> | |||
Torsten zond een patch naar SimGear en voegde een aantal debugberichten in de verdachte lus. (ze verschijnen alleen met "--log-level=debug" - voeg ook --log-classe=terrasync toe om de output enigszins beperkt te houden) <ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35063277/ | |||
|title = <nowiki>Re: [Flightgear-devel] FW: The future of terrasync</nowiki> | |||
|author = <nowiki>Torsten Dreyer</nowiki> | |||
|date = May 4th, 2016 | |||
|added = May 4th, 2016 | |||
|script_version = 0.31 | |||
}} | |||
</ref> | |||
We hebben nu C++ en Python referentievoorbeelden, beide hopelijk gemakkelijk te gebruiken. De C++ tool vind je hier: https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/io/http_repo_sync.cxx Ook hier zijn verbeteringen welkom. <ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35065868/ | |||
|title = <nowiki>Re: [Flightgear-devel] The future of terrasync</nowiki> | |||
|author = <nowiki>James Turner</nowiki> | |||
|date = May 5th, 2016 | |||
|added = May 5th, 2016 | |||
|script_version = 0.32 | |||
}} | |||
</ref> | |||
{{Appendix}} | |||