"মাল্টিকাস্ট সমর্থিত" একটি প্রোটোকল প্রশ্নের উত্তর দেয় এবং ক্যাপাসিটি প্রশ্নটি অক্ষত রেখে দেয়। পরিচালনাগতভাবে গুরুত্বপূর্ণ হলো সার্ভার একটি গ্রুপ প্যাকেটের জন্য কত কপি পাঠায় এবং কোন টানেল সেগুলো বহন করে। স্ট্রিম পেয়ে একটি সাবস্ক্রাইব করা অ্যাপ্লিকেশন শুধু প্রমাণ করে ডেলিভারি কোথাও কাজ করে। এটি প্রমাণ করে না যে অনিচ্ছুক ক্লায়েন্টদের ব্যান্ডউইথ বাঁচানো হয়েছে।

একটি ফিচার দাবির ভেতরে তিনটি প্রশ্ন

গ্রুপ মেম্বারশিপ জিজ্ঞাসা করে রিসিভার গ্রুপে যোগ দিয়েছে কি না। টানেল ডেলিভারি জিজ্ঞাসা করে প্যাকেটটি আদৌ টানেল পার হয়েছে কি না। রেপ্লিকেশন নীতি জিজ্ঞাসা করে সার্ভার কত কপি বানিয়েছে এবং কাকে দিয়েছে। একটি ভেন্ডর বিবৃতি প্রথমটির জন্য সত্য হতে পারে এবং তৃতীয়টি নিয়ে চুপ থাকতে পারে, আর খরচটা ঠিক সেখানেই থাকে।

লিঙ্কের মাপ নির্ধারণের সময় এগুলো আলাদা রাখুন। কেবল তৃতীয় প্রশ্নই সার্ভার পাশে আউটবাউন্ড বাজেট ঠিক করে।

ইউজারস্পেস সার্ভার একটি গ্রুপ প্যাকেট নিয়ে কী করে

OpenVPN 2.6-এর প্রচলিত ইউজারস্পেস সার্ভারে আসা একটি ব্রডকাস্ট বা মাল্টিকাস্ট প্যাকেট TUN/TAP ইনপুট পথে শ্রেণিবদ্ধ হয় এবং গ্রুপভিত্তিক লুকআপের বদলে ব্রডকাস্ট ফ্যান-আউট রুটিনে দেওয়া হয়। সেই রুটিন ক্লায়েন্ট ইনস্ট্যান্সগুলো ঘুরে দেখে, প্রেরক ও যেকোনো থামানো ইনস্ট্যান্স বাদ দেয়, যেখানে VLAN কনফিগার করা আছে সেখানে সেই পরীক্ষা প্রয়োগ করে, এবং বাকি প্রতিটি ক্লায়েন্টের জন্য একটি কপি সারিতে রাখে। সেই লুপের কোনো ধাপই মেম্বারশিপ টেবিল দেখে না। এটি ব্রডকাস্ট-ধাঁচের রেপ্লিকেশন, আর পুরো কার্যপ্রণালী এটাই।

এটিকে সেই কোড পথের একটি বৈশিষ্ট্য ধরুন, সার্বজনীন নিয়ম নয়। ত্বরান্বিত ডেটা পথ, অন্য বাস্তবায়ন ও ভিন্ন সংস্করণ ভিন্নভাবে আচরণ করতে পারে, এবং এর কোনোটিই TAP-কে আবশ্যক বা মেরামতের বিষয় করে না।

কিছু মাপার আগেই কপিগুলোর বাজেট করুন

পেলোড রেট নিন এবং যোগ্য ক্লায়েন্টের সংখ্যা দিয়ে গুণ করুন। সেকেন্ডে এক মেগাবিট পাঠানো একটি স্ট্রিম বিশজন ক্লায়েন্টের কাছে সেকেন্ডে বিশ মেগাবিট পেলোড তৈরি করে, যা এনক্যাপসুলেশন, পুনঃপ্রেরণ ও প্রতি-ক্লায়েন্ট ওভারহেডের আগেই সার্ভার ছাড়ে। সেই হিসাব একটি বাজেট, আপনার স্থাপনার পরিমাপ নয়।

ip -s link show tun0

একজন পরিচিত প্রেরক সক্রিয় রেখে নির্দিষ্ট বিরতির আগে ও পরে ট্রান্সমিট বাইট কাউন্টার পড়ুন। বিরত দিয়ে ভাগ করুন এবং পেলোড রেটকে ক্লায়েন্ট সংখ্যা দিয়ে গুণ করে তুলনা করুন। একক-স্ট্রিম রেটের কাছাকাছি সংখ্যা মানে রেপ্লিকেশন সীমিত পরিধির; গুণিত রেটের কাছাকাছি সংখ্যা মানে প্রতিটি ক্লায়েন্ট কপি পাচ্ছে।

কাউন্টারে আপনার নিজের টানেল ট্রাফিকও থাকে, তাই পরীক্ষার জানালা ছোট রাখুন এবং হোস্টকে অন্যথায় শান্ত রাখুন। নির্ভুলতা মাত্রার ক্রমের চেয়ে কম গুরুত্বপূর্ণ, আর একটি কপি থেকে বিশটি আলাদা করতে আপনার যা দরকার তাই।

দুই ক্লায়েন্টের একটি পরীক্ষা যা পরিধির প্রশ্ন নিষ্পত্তি করে

একটি ক্লায়েন্ট সংযুক্ত করুন যার স্ট্রিম পাওয়া উচিত, এবং দ্বিতীয়টি যা পাওয়া উচিত নয়। প্রেরক চালু করুন, তারপর একই বিরতির জন্য দ্বিতীয় ক্লায়েন্টের টানেল কাউন্টার দেখুন। দ্বিতীয় ক্লায়েন্টে বৃদ্ধি বিস্তৃত রেপ্লিকেশনের সরাসরি প্রমাণ, ফিচার তালিকা যা-ই বলুক।

ক্যাপচারটি গ্রুপ ঠিকানায় ফিল্টার করুন যাতে অসম্পর্কিত ট্রাফিক না পড়েন, এবং এটি টানেল ইন্টারফেসে সীমিত রাখুন। ব্যস্ত হোস্টে ফিজিক্যাল ইন্টারফেস ক্যাপচার করলে এমন ফাইল তৈরি হয় যা কেউ ব্যাখ্যা করতে পারে না, এবং আপনার সংগ্রহের ইচ্ছা না থাকা ব্যবহারকারী ডেটা রেখে দিতে পারে।

তারপর ভূমিকা উল্টে দিন। ফলাফল যদি গ্রুপের বদলে রিসিভারকে অনুসরণ করে, আপনি মেম্বারশিপ-সচেতন কিছু দেখছেন, এবং আগের অনুমানটি আপনার পক্ষে ভুল ছিল।

সীমা সরানোর বদলে সীমিত পরিধির ডিজাইন বাছাই করা

ফ্যান-আউট খুব প্রশস্ত হলে সমাধান হলো সমর্থিত সীমিত পরিধির বিতরণ ব্যবস্থা, আপনার সব নিয়ন্ত্রণ মুছে ফেলা নয়। বিকল্পগুলোর মধ্যে রয়েছে বিতরণ বিন্দু রিসিভারদের কাছাকাছি নেওয়া, সোর্স-নির্দিষ্ট সাবস্ক্রিপশন মডেল ব্যবহার করা যা গ্রুপের সঙ্গে সোর্সের পরিচয়ও বহন করে, বা স্ট্রিম ভাগ করা যাতে অনিচ্ছুক সাইটগুলো কখনো একই বিতরণ সীমায় না বসে।

সোর্স ও গ্রুপের পরিচয়কে গন্তব্য মাল্টিকাস্ট হওয়ার নিছক সত্য থেকে আলাদা রাখুন। যে রিসিভার গ্রুপ চেনে কিন্তু সোর্স চেনে না, সে নির্দিষ্ট চ্যানেল চাওয়া সাবস্ক্রাইবারের চেয়ে ভিন্ন সাবস্ক্রাইবার। দুটো মিশিয়ে দিলে পরের ক্যাপাসিটি পরিকল্পনা অনুমানে পরিণত হয়।

সোর্স-নির্দিষ্ট মাল্টিকাস্ট চ্যানেল মডেল এই পার্থক্যের রেফারেন্স। যে ডিজাইনই বেছে নিন, যোগ্য পিয়ার সেট, রেপ্লিকেশনের মালিক এবং পরের বার পড়বেন এমন কাউন্টার লিখে রাখুন; সেই রেকর্ডই ব্যান্ডউইথের অপ্রত্যাশিত খরচকে জানা খরচে বদলায়।

সম্পর্কিত নিবন্ধ