तार पर भेजने से पहले पैकेट को संपीड़ित करने के लिए उपयोग करने के लिए सबसे अच्छा संपीड़न एल्गोरिदम क्या होगा? पैकेट JSON का उपयोग करके एन्कोड किया गया है। क्या एलजेडब्लूडब्ल्यू इसके लिए अच्छा होगा या क्या कुछ बेहतर है?संपीड़न एल्गोरिदम?
मुझे लगता है कि दो सवाल अपने जवाब को प्रभावित करेगा:
1) आप जानते हुए भी क्या कार्यक्रम के किसी विशेष चलाने पर क्या होगा बिना डेटा की संरचना कितनी अच्छी तरह से भविष्यवाणी कर सकते हैं? उदाहरण के लिए, अपने पैकेट इस तरह दिखेगा यदि:
{
"vector": {
"latitude": 16,
"longitude": 18,
"altitude": 20
},
"vector": {
"latitude": -8,
"longitude": 13,
"altitude": -5
},
[... et cetera ...]
}
- तो आप शायद पाठ स्ट्रिंग्स कि आपके डेटा में प्रदर्शित रखना की एक हार्ड-कोडेड शब्दकोश बनाने के द्वारा अपने सबसे अच्छे संपीड़न हो और से प्रत्येक घटना की जगह लेंगे उपयुक्त शब्दकोश सूचकांक के साथ पाठ तारों में से एक। (असल में, यदि आपका डेटा नियमित रूप से नियमित है, तो आप शायद को तार पर मान भेजना चाहते हैं और किसी JSON ऑब्जेक्ट की आवश्यकता होने पर मानों से JSON ऑब्जेक्ट बनाने के लिए क्लाइंट में केवल एक फ़ंक्शन लिखना चाहते हैं।)
आप जो हेडर का उपयोग किया जाएगा, तो आप के माध्यम से डेटा यह एक विशेष रूप से में व्यक्त कर सकते हैं खोजने के लिए LZW, या LZ77, या किसी अन्य विधि है जो डेटा जो पहले से ही चला गया है पर लग रहा है उपयोग करना पड़ सकता अनुमान नहीं लगा सकते हैं कॉम्पैक्ट फॉर्म हालांकि ...
2) क्या पैकेट को एक-दूसरे से अलग से संपीड़ित करने की आवश्यकता है? यदि ऐसा है तो LZW निश्चित रूप से जिस विधि को आप चाहते हैं; इसमें अपने शब्दकोश को एक आकार तक बनाने का समय नहीं होगा जो एक ही पैकेट के अंत तक पर्याप्त संपीड़न परिणाम देगा। इस परिदृश्य में वास्तव में पर्याप्त संपीड़न प्राप्त करने का एकमात्र मौका, आईएमएचओ, एक हार्ड-कोडित शब्दकोश का उपयोग करना है।
(उपर्युक्त सभी में अनुपूरक: जैसा कि माइकल कोहेन बताते हैं, जेएसओएन भेजना मतलब है कि आप शायद सभी पाठ भेज रहे हैं, जिसका अर्थ है कि आप बैंडविड्थ को कम कर रहे हैं जिसमें पात्रों की एक विस्तृत श्रृंखला भेजने की क्षमता है आप इसका उपयोग कर रहे हैं। हालांकि, 0-127 रेंज में आने वाले वर्णों को पैक करने के लिए समस्याएं जो कि 0-255 मान रखती हैं, काफी सरल है और मुझे लगता है कि "पाठक के लिए एक अभ्यास" के रूप में छोड़ा जा सकता है, क्योंकि वे कहें।)
उम्म्म ... अगर मैं गलत हूं, तो मुझे सही करें, लेकिन यदि आप ऑन-द-वायर संपीड़न को कार्यान्वित कर रहे हैं, तो आप कनेक्शन के दोनों सिरों को नियंत्रित करते हैं, है ना? उस स्थिति में, यदि JSON बहुत प्रोटोकॉल है, तो आप एक अलग वायर प्रोटोकॉल क्यों नहीं चुनेंगे जो वसा नहीं है? मेरा मतलब है, मैं जेएसओएन जैसे मानक का उपयोग करने की अपील को समझता हूं, लेकिन यदि आप बैंडविड्थ के बारे में चिंतित हैं, तो आपको शायद एक वायर प्रोटोकॉल चुनना चाहिए जो सभी पाठ नहीं है।
"तो आपको शायद एक तार प्रोटोकॉल चुनना चाहिए जो कि सभी पाठ नहीं है" उदाहरण के लिए? (+1 यदि आप दो या अधिक नाम देते हैं ;-) – tobsen
@tobsen [TCP] (http://tools.ietf.org/html/rfc793), [आईपी] (http://tools.ietf.org/html/ आरएफसी 7 9 1), [यूडीपी] (http://tools.ietf.org/html/rfc768)? लेकिन फिर भी, पूरा वेब उम्र के बाद से HTTP का उपयोग करता है और कभी भी कोई समस्या नहीं होती ([एसपीडीवाई] (http://www.chromium.org/spdy/spdy-whitepaper/) काम पर है)। –
इसके अलावा, पाठ बनाम बाइनरी के संबंध में ... सभी रजिस्ट्री के लिनक्स दृष्टिकोण के साथ विंडोज रजिस्ट्री की तुलना करें और मुझे बताएं कि तेज़ क्या है ... पाठ का मतलब धीमा नहीं है। –
वेबसर्वर संपीड़ित करने दें और ब्राउज़र को मूल रूप से डिकंप्रेस करें; gzip या deflate।
यह एक वेब सर्वर नहीं है। ग्राहक एक फ्लैश प्रोग्राम है। – ryeguy
गीज़िप (डिफ्लेट एल्गोरिदम) संपीड़न पर बहुत अच्छा है, हालांकि सभी अच्छे संपीड़न एल्गोरिदम की तरह, सीपीयू के बहुत सारे उपयोग करता है (3-5x जितना अधिक मेरे परीक्षण पर जेसन पढ़ने/लिखने के ऊपर)।
दो और JSON संपीड़न एल्गोरिदम हैं: CJson & HPack एचपीएक्स बहुत अच्छा काम करता है, जो कि जीजीआईपी संपीड़न के समान है।
यहाँ JSON डेटा के दबाव पर एक संक्षिप्त परीक्षा है मूल: https://github.com/lsauer/Data-Hub: अपराध से data_geojson.json 72844By (आप यहाँ फ़ाइल प्राप्त कर सकते हैं।फ़ाइल यादृच्छिक पर चुना गया था लेकिन औसत JSON डेटा का प्रतिनिधि)
जिप के अलावासभी archiver मापदंडों अल्ट्रा
* cm/ nanozip:
> 4076/72844
[1] 0.05595519
* gzip:
> 6611/72844
[1] 0.09075559
* LZMA/7zip
> 5864/72844
[1] 0.0805008
* Huffman/zip:
> 7382/72844
[1] 0.1013398
* ?/Arc:
> 4739/72844
[1] 0.06505683
पर सेट होने पर इसका मतलब यह है कि संपीड़न बहुत ही उच्च और फायदेमंद है नहीं हो सकता। जेएसओएन डेटा में आमतौर पर एक उच्च एन्ट्रॉपी होती है। विकिपीडिया के अनुसार
अंग्रेजी पाठ के एन्ट्रापी दर 1.0 और 1.5 के बीच पत्र बिट्स प्रति है, [1] के रूप में या कम पत्र प्रति 0.6 1.3 करने के लिए बिट्स, मानव प्रयोगों
के आधार पर अनुमान शैनन द्वारा के अनुसार के रूप में
JSON डेटा का एन्ट्रॉपी अक्सर उस से ऊपर है। (लगभग एक समान आकार के 10 मनमानी जेएसओएन फाइलों के साथ एक प्रयोग में मैंने 2.36 की गणना की)
मैं अकेला नहीं हूं जो नैनोज़िप के बारे में जानता है! +1: डी (लेकिन मैं इसे वायर लॉल पर कभी नहीं इस्तेमाल करूंगा) –
उपर्युक्त उदाहरण के लिए, एओएस प्रारूप के बजाय एसओए में भंडारण डेटा को बहुत कम करता है। मैंने पाया कि बहुत से मामलों के लिए यह एक अच्छा 'संपीड़न' विधि है लेकिन यह एसओए उपयुक्त होने पर विशिष्ट अनुप्रयोग पर निर्भर करता है। – Chris
2 में सलाह भ्रमित है - क्या प्रत्येक पैकेट बड़ा होने पर भी LZW सही विधि नहीं है? क्या होगा अगर पैकेट को अलग से संपीड़ित करने की आवश्यकता न हो? इस पैकिंग 0-255 में 0-127 के बारे में कोई भी विवरण या लिंक उपयोगी होगा –
यह 0-127 में 0-255 पैक कर रहा है, न कि दूसरी तरफ। एएससीआईआई 8-बिट बाइट्स का उपयोग करता है, लेकिन मानक पाठ के पात्र केवल निम्न 7 बिट्स का उपयोग करते हैं; अन्य 128 वर्ण, जो उच्चतम बिट 1 को सेट करते हैं, नियंत्रण वर्ण हैं। पात्रों को पैक करने के लिए, आप प्रत्येक आठवें चरित्र लेते हैं और पिछले 7 अक्षरों के अप्रयुक्त 'उच्च बिट्स' के बीच अपने सात डेटा बिट्स को विभाजित करते हैं। – afeldspar