Migration From V4

রূপান্তর তালিকা আপডেট

V4 এর বিপরীতে, যেখানে তালিকাগুলি হুমকির ধরন, প্ল্যাটফর্মের ধরন, হুমকি এন্ট্রি টাইপ দ্বারা চিহ্নিত করা হয়, v5 তালিকাগুলি কেবল নাম দ্বারা চিহ্নিত করা হয়। এটি নমনীয়তা প্রদান করে যখন একাধিক v5 তালিকা একই হুমকি প্রকার ভাগ করতে পারে। প্ল্যাটফর্মের ধরন এবং হুমকির এন্ট্রি প্রকারগুলি v5 এ সরানো হয়েছে।

v4-এ, তালিকাগুলি ডাউনলোড করার জন্য একজন হুমকিListUpdates.fetch পদ্ধতি ব্যবহার করবে। v5-এ, একজন hashLists.batchGet পদ্ধতিতে স্যুইচ করবে।

অনুরোধে নিম্নলিখিত পরিবর্তনগুলি করা উচিত:

1. সম্পূর্ণভাবে v4 ClientInfo অবজেক্ট সরান। একটি ডেডিকেটেড ফিল্ড ব্যবহার করে ক্লায়েন্টের শনাক্তকরণ সরবরাহ করার পরিবর্তে, শুধুমাত্র সুপরিচিত User-Agent হেডার ব্যবহার করুন। যদিও এই শিরোনামে ক্লায়েন্ট সনাক্তকরণ সরবরাহ করার জন্য কোনও নির্ধারিত বিন্যাস নেই, আমরা কেবল একটি স্পেস অক্ষর বা একটি স্ল্যাশ অক্ষর দ্বারা পৃথক করা মূল ক্লায়েন্ট আইডি এবং ক্লায়েন্ট সংস্করণ অন্তর্ভুক্ত করার পরামর্শ দিই।
2. প্রতিটি v4 ListUpdateRequest অবজেক্টের জন্য: * উপরের টেবিলে সংশ্লিষ্ট v5 তালিকার নামটি দেখুন এবং v5 অনুরোধে সেই নামটি সরবরাহ করুন।
   • threat_entry_type বা platform_type মতো অপ্রয়োজনীয় ক্ষেত্রগুলি সরান।
   • v4-এর state ক্ষেত্রটি সরাসরি v5 versions ক্ষেত্রের সাথে সামঞ্জস্যপূর্ণ। একই বাইট স্ট্রিং যা v4-এ state ফিল্ড ব্যবহার করে সার্ভারে পাঠানো হবে versions ফিল্ড ব্যবহার করে v5-এ পাঠানো যেতে পারে।
   • v4 সীমাবদ্ধতার জন্য, v5 SizeConstraints নামে একটি সরলীকৃত সংস্করণ ব্যবহার করে। অতিরিক্ত ক্ষেত্র যেমন region বাদ দেওয়া উচিত।

প্রতিক্রিয়াতে নিম্নলিখিত পরিবর্তনগুলি করা উচিত:

1. v4 enum ResponseType টিকে কেবল partial_update নামে একটি বুলিয়ান ক্ষেত্র দ্বারা প্রতিস্থাপিত করা হয়েছে।
2. minimum_wait_duration ক্ষেত্রটি এখন শূন্য বা বাদ দেওয়া যেতে পারে। যদি তা হয়, ক্লায়েন্টকে অবিলম্বে আরেকটি অনুরোধ করতে অনুরোধ করা হচ্ছে। এটি শুধুমাত্র তখনই ঘটে যখন ক্লায়েন্ট SizeConstraints এ সর্বাধিক ডেটাবেস আকারের চেয়ে সর্বাধিক আপডেটের আকারে একটি ছোট সীমাবদ্ধতা নির্দিষ্ট করে।
3. 32-বিট পূর্ণসংখ্যার জন্য রাইস ডিকোডিং অ্যালগরিদম সামঞ্জস্য করতে হবে। পার্থক্য হল যে এনকোড করা তথ্য একটি ভিন্ন endianness সঙ্গে এনকোড করা হয়. v4 এবং v5 উভয় ক্ষেত্রেই, 32-বিট হ্যাশ উপসর্গগুলি অভিধানিকভাবে সাজানো হয়েছে। কিন্তু v4 তে, সাজানো হলে সেই উপসর্গগুলিকে ছোট এন্ডিয়ান হিসাবে ধরা হয়, যেখানে v5 তে এই উপসর্গগুলিকে সাজানোর সময় বড় এন্ডিয়ান হিসাবে ধরা হয়। এর মানে হল যে ক্লায়েন্টকে কোনও সাজানোর দরকার নেই, যেহেতু অভিধানিক বাছাই বড় এন্ডিয়ানের সাথে সংখ্যাসূচক সাজানোর মতো। V4 এর Chromium বাস্তবায়নে এই ধরণের একটি উদাহরণ এখানে পাওয়া যাবে। এই ধরনের বাছাই অপসারণ করা যেতে পারে.
4. অন্যান্য হ্যাশ দৈর্ঘ্যের জন্যও রাইস ডিকোডিং অ্যালগরিদম প্রয়োগ করতে হবে।

হ্যাশ অনুসন্ধান রূপান্তর

v4 তে, একজন সম্পূর্ণ হ্যাশ পেতে fullHashes.find পদ্ধতি ব্যবহার করবে। v5 এর সমতুল্য পদ্ধতি হল hashes.search পদ্ধতি ।

অনুরোধে নিম্নলিখিত পরিবর্তনগুলি করা উচিত:

1. শুধুমাত্র 4 বাইট দৈর্ঘ্যের হ্যাশ প্রিফিক্স পাঠানোর জন্য কোডটি গঠন করুন।
2. সম্পূর্ণভাবে v4 ClientInfo অবজেক্টগুলি সরান। একটি ডেডিকেটেড ফিল্ড ব্যবহার করে ক্লায়েন্টের শনাক্তকরণ সরবরাহ করার পরিবর্তে, শুধুমাত্র সুপরিচিত User-Agent হেডার ব্যবহার করুন। যদিও এই শিরোনামে ক্লায়েন্ট সনাক্তকরণ সরবরাহ করার জন্য কোনও নির্ধারিত বিন্যাস নেই, আমরা কেবল একটি স্পেস অক্ষর বা একটি স্ল্যাশ অক্ষর দ্বারা পৃথক করা মূল ক্লায়েন্ট আইডি এবং ক্লায়েন্ট সংস্করণ অন্তর্ভুক্ত করার পরামর্শ দিই।
3. client_states ক্ষেত্রটি সরান। এর আর প্রয়োজন নেই।
4. threat_types এবং অনুরূপ ক্ষেত্র অন্তর্ভুক্ত করার আর প্রয়োজন নেই।

প্রতিক্রিয়াতে নিম্নলিখিত পরিবর্তনগুলি করা উচিত:

1. minimum_wait_duration ক্ষেত্রটি সরানো হয়েছে। ক্লায়েন্ট সর্বদা প্রয়োজনীয় ভিত্তিতে একটি নতুন অনুরোধ জারি করতে পারে।
2. v4 ThreatMatch অবজেক্টটিকে FullHash অবজেক্টে সরলীকৃত করা হয়েছে।
3. ক্যাশিংকে একটি একক ক্যাশে মেয়াদে সরলীকৃত করা হয়েছে। ক্যাশের সাথে ইন্টারঅ্যাক্ট করার জন্য উপরের পদ্ধতিগুলি দেখুন।