ज़िम्मेदारी के साथ डाउनलोड करें

• इस महीने डाउनलोड सर्वर के infrastructure upgrade के कारण अब डाउनलोड का अनुभव और तेज़ होगा
• “…latest” फ़ाइल अनुरोध का तरीका अब HTTP redirect में बदल दिया गया है
• सभी उपयोगकर्ता आसानी से नवीनतम OSM डेटा तक पहुंच सकें, इसके लिए प्रयास किया जा रहा है
• बड़े आकार की फ़ाइलों को बार-बार अत्यधिक डाउनलोड करने वाले असामान्य उपयोग पैटर्न से पूरी सेवा की performance प्रभावित होती है
• कुशल और ज़िम्मेदार डाउनलोड के लिए तीन ठोस सिफारिशें दी गई हैं

---

डाउनलोड सर्वर अपडेट और ज़िम्मेदार उपयोग की अपील

इस महीने डाउनलोड सर्वर के infrastructure को मज़बूत करने का काम किया गया।
इससे ऐसा वातावरण बन सका है जिसमें डाउनलोड और तेज़, और जल्दी उपलब्ध कराए जा सकें।
तकनीकी बदलाव के तहत, “…latest” फ़ाइल अनुरोध पर अब पहले की तरह फ़ाइल सीधे देने के बजाय HTTP redirect के माध्यम से नवीनतम संस्करण की फ़ाइल तक पहुंचाया जाता है

ज़िम्मेदार डाउनलोड की ज़रूरत

सर्वर इस तरह चलाया जा रहा है कि सभी उपयोगकर्ता आसानी से नवीनतम OSM(OpenStreetMap) डेटा तक पहुंच सकें।
लेकिन कुछ मामलों में उपयोगकर्ता एक ही बड़ी फ़ाइल (जैसे 20GB) को दिन में सैकड़ों या हज़ारों बार बार-बार डाउनलोड करते पाए गए हैं

• उदाहरण के तौर पर, एक उपयोगकर्ता ने 24 घंटे के भीतर italy-latest.osm.pbf फ़ाइल को लगभग 10,000 बार डाउनलोड किया
• कुछ अन्य उपयोगकर्ता सर्वर की सभी फ़ाइलों को हर दिन पूरा का पूरा डाउनलोड बार-बार करते रहे

ऐसा व्यवहार सर्वर की bandwidth limits के कारण सभी उपयोगकर्ताओं के लिए सेवा को धीमा कर देता है
अगर IP range को block करना अपरिहार्य हो जाए, तो असंबंधित उपयोगकर्ताओं को भी नुकसान उठाना पड़ सकता है

सर्वर उपयोगकर्ताओं के लिए तीन ठोस सिफारिशें

1. अगर आपको पूरी दुनिया का डेटा चाहिए, तो उसे सर्वर से हिस्सों में लेने के बजाय planet.openstreetmap.org से planet फ़ाइल एक बार में डाउनलोड करने की सलाह दी जाती है
2. यदि आप महाद्वीप या बड़े क्षेत्र के डेटा (जैसे Europe, North America) को रोज़ अपडेट करना चाहते हैं, तो pyosmium-up-to-date प्रोग्राम का उपयोग करके केवल बदलाव डाउनलोड करें; इससे कुल ट्रैफ़िक का 98% तक बचाया जा सकता है और गति भी तेज़ होती है
3. यदि आप automation scripts का उपयोग करते हैं, तो क्या डाउनलोड हो रहा है इसे monitor करें, या उचित error handling जोड़ें, ताकि एक ही फ़ाइल का अनंत बार दोहराया जाने वाला डाउनलोड जैसी गलतियों से बचा जा सके

निष्कर्ष

और अधिक ज़िम्मेदार डाउनलोड आदतों के साथ ऐसा बेहतर वातावरण बनाने में सहयोग करने का अनुरोध है, जहाँ सभी लोग आराम से नवीनतम डेटा का उपयोग कर सकें

[GN⁺]

Hacker News राय

• जब भी मैं ऐसे मिलते-जुलते मुद्दे देखता हूँ, मुझे हैरानी होती है कि BitTorrent का ज़्यादा इस्तेमाल क्यों नहीं होता। अच्छा होता अगर यह और जगहों पर default protocol के रूप में इस्तेमाल होता, जैसे container registry या package repository में।
  • BitTorrent की आम लोगों के बीच छवि अच्छी नहीं है; ज़्यादातर लोग इसे सिर्फ़ illegal download से जोड़ते हैं.<br>Firewall configuration, HTTP की तुलना में, ज़्यादा मुश्किल है। Network administrator से ऐसी setting माँगें तो वे इसे अजीब समझ सकते हैं, खासकर BitTorrent को लेकर मौजूद नकारात्मक धारणा के कारण।<br>BitTorrent client, HTTP client से कहीं ज़्यादा complex होते हैं और आम तौर पर company computer या CI pipeline में install नहीं होते। बहुत से लोग चाहते हैं कि काम सिर्फ़ एक curl command से हो जाए।<br>Seeding करनी पड़ेगी, इस बारे में बहुत ग़लतफ़हमी है, और उसी वजह से लोग डरते हैं।<br>आख़िरकार, सिर्फ़ image और curl से सब कुछ हो जाने की वजह से BitTorrent कम आंका जाता है, यह अफ़सोस की बात है।<br>Video game client के update में BT के इस्तेमाल या PeerTube द्वारा webtorrent के उपयोग जैसे उदाहरण हैं, लेकिन फिर भी इसका उपयोग बहुत आम नहीं है, यह खलता है।
  • Amazon, Esri, Grab, Hyundai, Meta, Microsoft, Precisely, Tripadvisor, TomTom जैसी दर्जनों कंपनियाँ OpenStreetMap data को Parquet format में S3 पर मुफ़्त उपलब्ध करा रही हैं। इससे कई TB के dataset में से सिर्फ़ MB स्तर की bandwidth खर्च करके मनचाही जानकारी query और analyze की जा सकती है.<br>ज़्यादा जानकारी के लिए विस्तार से देखें.<br>ArcGIS Pro user इस plugin का भी उपयोग कर सकते हैं.
  • कुछ साल पहले मुझे "dynamic content वाले torrent" की अवधारणा देखने की याद है, लेकिन वह व्यवहार में ज़्यादा इस्तेमाल नहीं हुई।
  • मैं चाहता था कि यह सच में कामयाब हो, इसलिए सोचता हूँ क्या security issue जैसी कोई गंभीर समस्या थी। संदर्भ लिंक
  • HTTP की तुलना में BitTorrent में अपने आप में ऐसा "universal client" कमज़ोर रहा है जिसे हर जगह इस्तेमाल किया जा सके। यह SSH या SCP जितना परिचित भी नहीं है, और installation, configuration, tracker setup तक काफ़ी मेहनत लगती है। आम तौर पर इस तरह की संरचना तभी मायने रखती है जब बड़े फ़ाइलों की बार-बार download की ज़रूरत हो। Reliability और seeding volume जैसी बातों को भी देखें तो बात आख़िरकार इस पर आकर टिकती है कि tool development और maintenance cost के मुकाबले फ़ायदा कितना है। Git LFS जैसी चीज़ मदद कर सकती है या नहीं, बस यहीं तक मेरी जानकारी है।
  • जिस कंपनी में मैं पहले काम करता था, वहाँ हर हफ़्ते सभी developer को बड़े फ़ाइल distribute करने पड़ते थे। शुरू में हम rsync से सबको एक साथ खींचने देते थे, लेकिन BitTorrent पर बदलने के बाद speed में बहुत बड़ा सुधार हुआ।
• Geofabrik जैसी कंपनी है, इसलिए हमें कभी-कभी इतने अच्छे अनुभव मिल जाते हैं, इसके लिए मैं हमेशा आभारी हूँ। जब आप खुद API चलाते हैं, तो developer की लापरवाही या अज्ञानता देखकर सच में हैरानी होती है। इतनी अजीब requests बहुत बार आती हैं। अगर मैंने खुद पहले यह अनुभव न किया होता, और कोई मुझे यह बताता, तो मैं इसे बढ़ा-चढ़ाकर कही गई बात समझता। लेकिन दूसरी तरफ़, API developer भी अक्सर कई मामलों को ध्यान में नहीं रखते। वे ज़्यादातर सिर्फ़ single entity manipulation देते हैं, जबकि असली use case में multiple operation चाहिए होते हैं, और तब 700 request भेजने के अलावा विकल्प नहीं बचता।
  • कम अनुभवी लोगों में किसी भी पेशे में गैर-जिम्मेदारी और अज्ञानता हो सकती है। मुझे यक़ीन है कि सारे developer API को बेतहाशा नहीं पीटते। Programming अब सबके लिए खुल गई है, और हाल में "vibe-coding" जैसा रुझान भी है, इसलिए बड़े परिप्रेक्ष्य में यह कुछ हद तक अपरिहार्य लगता है। अगर response में 429(Too Many Requests) लौटाया जाए या leaky-bucket algorithm लगाया जाए, तो junior या beginner developer भी जल्दी खुद समझ जाएँगे कि समस्या क्या है।
  • S3 का "downloader pays" feature ज़्यादा व्यापक रूप से क्यों नहीं अपनाया गया, यह समझना मुश्किल है। अगर AWS के बाहर भी ऐसा model हो, तो inefficient user अपने हिस्से की लागत खुद उठा सकते हैं। नुकसान यह है कि जिन लोगों के पास payment system नहीं है, उनके लिए access मुश्किल हो सकता है। लेकिन क्या ऐसा नहीं हो सकता कि free but limited speed वाला विकल्प भी रखा जाए?
  • कहा जा रहा है कि कोई user 20GB फ़ाइल को दिन में हज़ारों बार डाउनलोड कर रहा है; ऐसे में यह समझ नहीं आता कि इसे साधारण Rate Limit से क्यों नहीं नियंत्रित किया जाता।
  • मेरा मानना है कि दोनों तरफ़ ज़्यादा empathy की ज़रूरत है: client को infrastructure का सम्मान करना चाहिए, और API developer को user के नज़रिए से ज़्यादा व्यापक रूप से सोचना चाहिए।
• "एक user ने 24 घंटे के भीतर italy-latest.osm.pbf फ़ाइल को लगभग दस हज़ार बार डाउनलोड किया" — ऐसा मामला होने पर code में समस्या होने की संभावना ज़्यादा है। IP per limit लगा देने से काम हो जाना चाहिए। VPN user हो तो भी।
• शायद लोग CI pipeline में map data file डाउनलोड कर रहे हैं, और कई बार यह अनजाने में होने वाला download होता है जिसकी उन्हें खुद भी जानकारी नहीं होती.<br>इसीलिए बहुत सी services ने non-member की automatic download पर रोक लगा दी है.<br>मेरा मानना है कि cURL से फ़ाइल लेने से पहले signup कराना चाहिए, और जो user बहुत ज़्यादा डाउनलोड करें उन्हें block करना या शुल्क लेना चाहिए.
  • मुझे लगता है CI का विचार computing resource बर्बाद करने वाले सबसे ख़राब आविष्कारों में से एक है, लेकिन map data के मामले में code library जैसी दुरुपयोग वाली mass download क्यों होती है, यह मैं ठीक से नहीं समझता।
  • मुझे शक है कि webapp शायद GPKG file को "query" कर रहा हो। Parquet format में मनचाहा हिस्सा efficient तरीके से query किया जा सकता है, लेकिन GPKG में वही चीज़ उतनी आसानी से संभव है या नहीं, यह मुझे नहीं पता।
  • मैं जानना चाहता हूँ कि क्या CI server से आने वाली request को भरोसेमंद ढंग से पहचाना जा सकता है।
  • साधारण authentication, जैसे API key या email-based verification, भी अच्छा समझौता हो सकता है।
• "एक user कई दिनों तक एक ही 20GB फ़ाइल को दिन में सैकड़ों बार डाउनलोड कर रहा है (24 घंटे में दस हज़ार बार डाउनलोड करने वाला user भी था), और कुछ लोग server पर मौजूद सारी फ़ाइलें रोज़ डाउनलोड करते हैं" — ऐसा मामला तो rate-limiting से आसानी से रोका जा सकता है।<br>जब 24 घंटे के दौरान file download count पहले से गिना जा रहा है, तो limit न लगाने की वजह क्या है, यह समझ नहीं आता।<br>मुझे नहीं लगता कि ये लोग (a) server operator की warning post पढ़ेंगे और (b) अपना व्यवहार बदलेंगे।
• कुछ साल पहले मैं सोचता था, "भला कौन build script में हर बार 100MB से ज़्यादा चीज़ डाउनलोड करेगा?" लेकिन Docker का अनुभव होने के बाद समझ आया कि ऐसे मामले बहुत आम हैं।
  • मैं अक्सर ऐसे मामले देखता हूँ जहाँ container के अंदर पहुँचते ही लोग मान लेते हैं कि जैसे सब कुछ जादुई रूप से मुफ़्त हो गया हो।
  • Docker layer cache support करता है, तो क्या हर बार सब कुछ फिर से fresh डाउनलोड करना ज़रूरी है?
  • इसलिए मैं project-specific image पहले से CI के लिए बना देता हूँ और उसे सिर्फ़ CI में इस्तेमाल करता हूँ। हर बार apt-get से setup करना बहुत समय खाता है।
• मैं जानना चाहता हूँ कि क्या बहुत ज़्यादा डाउनलोड करने वाले user को अलग से email भेजा जाता है। 2012 में जब मैंने मुफ़्त Nominatim API इस्तेमाल किया था, तब email अनिवार्य था, और caching वगैरह से request कम करने की सलाह वाला mail मुझे सच में मिला था।
  • अगर login ही नहीं है, तो email address भी नहीं मिलेगा, इसलिए mail भेजना संभव नहीं होगा।
• मैं वह user नहीं हूँ जो italy-latest फ़ाइल हर 8 सेकंड में डाउनलोड करता है, लेकिन जिस Italian startup से मैं जुड़ा हूँ, वह GeoFabrik का बहुत इस्तेमाल करता है, और टीम में किसी ने container experiment करते हुए शायद ज़रूरत से ज़्यादा डाउनलोड कर लिया हो।<br>पहले हमें geofabrik से block (ban) किया गया था, लेकिन आज तक कारण पता नहीं चल पाया, इसलिए उम्मीद है कि आगे ऐसा दोबारा न हो।<br>मैंने geofabrik.de के contact पर phone और email दोनों से संपर्क करने की कोशिश की, लेकिन कोई जवाब नहीं मिला। अगर किसी को इस समस्या को सुलझाने का तरीका या सही संपर्क माध्यम पता हो, तो बताएं।
• लगता है इस तरह ज़रूरत से ज़्यादा फ़ाइल डाउनलोड करने वाले लोग वैसे भी ऐसे blog post नहीं पढ़ेंगे।
• यह मुझे ऐसा use case लगता है जहाँ bittorrent अच्छा रहेगा।
  • अगर data बदलता है, तो क्या torrent client अपने आप सिर्फ़ बदले हुए हिस्से ही ला सकता है, यह जानने की जिज्ञासा है।