Migration From V4

बदलावों की सूची को बदलना

V4 में, सूचियों की पहचान थ्रेट टाइप, प्लैटफ़ॉर्म टाइप, और थ्रेट एंट्री टाइप के टपल से की जाती है. हालांकि, v5 में सूचियों की पहचान सिर्फ़ नाम से की जाती है. इससे, एक ही तरह के खतरे की जानकारी को कई v5 सूचियों के साथ शेयर करने में आसानी होती है. पांचवें वर्शन में, प्लैटफ़ॉर्म टाइप और थ्रेट एंट्री टाइप हटा दिए गए हैं.

वर्शन 4 में, सूचियां डाउनलोड करने के लिए threatListUpdates.fetch method का इस्तेमाल किया जाता था. v5 में, hashLists.batchGet method पर स्विच किया जाएगा.

अनुरोध में ये बदलाव किए जाने चाहिए:

1. v4 ClientInfo ऑब्जेक्ट को पूरी तरह से हटा दें. क्लाइंट की पहचान करने के लिए, किसी खास फ़ील्ड का इस्तेमाल करने के बजाय, User-Agent हेडर का इस्तेमाल करें. इस हेडर में क्लाइंट की पहचान देने के लिए, कोई तय फ़ॉर्मैट नहीं है. हालांकि, हमारा सुझाव है कि इसमें सिर्फ़ ओरिजनल क्लाइंट आईडी और क्लाइंट वर्शन शामिल करें. इन दोनों को स्पेस या स्लैश से अलग करें.
2. हर v4 ListUpdateRequest ऑब्जेक्ट के लिए:
   • उपलब्ध सूचियों में जाकर, v5 की सूची का नाम देखें और v5 के अनुरोध में उस नाम को शामिल करें.
   • threat_entry_type या platform_type जैसे गैर-ज़रूरी फ़ील्ड हटाएं.
   • वर्शन 4 में मौजूद state फ़ील्ड, वर्शन 5 में मौजूद versions फ़ील्ड के साथ सीधे तौर पर काम करता है. v4 में state फ़ील्ड का इस्तेमाल करके सर्वर को भेजी जाने वाली बाइट स्ट्रिंग को, v5 में versions फ़ील्ड का इस्तेमाल करके भेजा जा सकता है.
   • v4 की पाबंदियों के लिए, v5 में SizeConstraints नाम का आसान वर्शन इस्तेमाल किया जाता है. region जैसे अतिरिक्त फ़ील्ड हटा दिए जाने चाहिए.

जवाब में ये बदलाव किए जाने चाहिए:

1. v4 enum ResponseType को partial_update नाम के बूलियन फ़ील्ड से बदल दिया जाता है.
2. minimum_wait_duration फ़ील्ड की वैल्यू अब शून्य हो सकती है या इसे छोड़ा जा सकता है. अगर ऐसा होता है, तो क्लाइंट से तुरंत दूसरा अनुरोध करने के लिए कहा जाता है. ऐसा सिर्फ़ तब होता है, जब क्लाइंट SizeConstraints में, डेटाबेस के ज़्यादा से ज़्यादा साइज़ की तुलना में अपडेट के ज़्यादा से ज़्यादा साइज़ पर कम पाबंदी लगाता है.
3. 32-बिट पूर्णांकों के लिए, राइस डिकोडिंग एल्गोरिदम को अडजस्ट करना होगा. इनमें अंतर यह है कि एन्कोड किए गए डेटा को अलग-अलग एंडियननेस के साथ एन्कोड किया जाता है. v4 और v5, दोनों में 32-बिट हैश प्रीफ़िक्स को लेक्सिकोग्राफ़िक तरीके से क्रम से लगाया जाता है. हालांकि, v4 में सॉर्ट करते समय उन प्रीफ़िक्स को लिटिल एंडियन माना जाता है. वहीं, v5 में सॉर्ट करते समय उन प्रीफ़िक्स को बिग एंडियन माना जाता है. इसका मतलब है कि क्लाइंट को किसी भी तरह की सॉर्टिंग करने की ज़रूरत नहीं है, क्योंकि लेक्सिकोग्राफ़िक सॉर्टिंग, बिग एंडियन के साथ न्यूमेरिक सॉर्टिंग के जैसी ही होती है. Chromium में v4 को लागू करने के दौरान, इस तरह के उदाहरण यहां देखे जा सकते हैं. इस तरह की सॉर्टिंग को हटाया जा सकता है.
4. राइस डिकोडिंग एल्गोरिदम को अन्य हैश लेंथ के लिए भी लागू करना होगा.

हैश की गई खोजों को बदला जा रहा है

v4 में, पूरे हैश पाने के लिए fullHashes.find method का इस्तेमाल किया जाता था. पांचवें वर्शन में, इससे मिलता-जुलता तरीका the hashes.search method है.

अनुरोध में ये बदलाव किए जाने चाहिए:

1. कोड को इस तरह से स्ट्रक्चर करें कि सिर्फ़ ऐसे हैश प्रीफ़िक्स भेजे जाएं जिनकी लंबाई ठीक चार बाइट हो.
2. v4 ClientInfo ऑब्जेक्ट को पूरी तरह से हटा दें. क्लाइंट की पहचान करने के लिए, किसी खास फ़ील्ड का इस्तेमाल करने के बजाय, User-Agent हेडर का इस्तेमाल करें. इस हेडर में क्लाइंट की पहचान देने के लिए, कोई तय फ़ॉर्मैट नहीं है. हालांकि, हमारा सुझाव है कि इसमें सिर्फ़ ओरिजनल क्लाइंट आईडी और क्लाइंट वर्शन शामिल करें. इन दोनों को स्पेस या स्लैश से अलग करें.
3. client_states फ़ील्ड हटाएं. अब इसकी ज़रूरत नहीं है.
4. अब threat_types और मिलते-जुलते फ़ील्ड शामिल करने की ज़रूरत नहीं है.

जवाब में ये बदलाव किए जाने चाहिए:

1. minimum_wait_duration फ़ील्ड को हटा दिया गया है. क्लाइंट, ज़रूरत के हिसाब से हमेशा नया अनुरोध जारी कर सकता है.
2. v4 ThreatMatch ऑब्जेक्ट को FullHash ऑब्जेक्ट में बदल दिया गया है.
3. कैशिंग को आसान बना दिया गया है. अब कैश मेमोरी को सिर्फ़ एक अवधि के लिए सेव किया जा सकता है. कैश मेमोरी के साथ इंटरैक्ट करने के लिए, ऊपर दी गई प्रोसेस देखें.