ক্লায়েন্ট কী অর্জন করলে (A) সার্ভার নিম্নলিখিত তিনটির একটি দিয়ে সাড়া দেয়।
| কী-এর অবস্থা | সার্ভারের কাজ | সাড়া |
|---|---|---|
| নিবন্ধিত নয় | সাথে সাথে নিবন্ধন (মেয়াদ = now + lease), টোকেন ইস্যু | A + token + key |
| নিবন্ধিত + মেয়াদ পার হয়েছে | পুনর্নবীকরণ (now + lease), নতুন টোকেন ইস্যু | A + token + key |
| নিবন্ধিত + বৈধ (দখলে) | সারিতে নিবন্ধন, সাড়া মুলতবি | রিলিজ/মেয়াদোত্তীর্ণ হলে A, wait অতিক্রম করলে T |
R) করলে সারির সর্বাগ্রে থাকা ব্যক্তির কাছে সরাসরি হস্তান্তর হয় — পুনঃপ্রতিযোগিতা ছাড়াই নতুন টোকেনসহ সাথে সাথে চলে যায়।lease একটি নিরাপত্তা জাল। ক্লায়েন্ট মারা গেলে বা রিলিজ করতে ভুলে গেলেও, lease-এর সময় পার হলে সার্ভার স্বয়ংক্রিয়ভাবে কী পুনরুদ্ধার করে পরবর্তী অপেক্ষমাণকে দিতে পারে। তাই স্বাভাবিক রিলিজ প্রবাহের বাইরেও lease সবসময় পর্যাপ্ত, কিন্তু মারা গেলে খুব বেশি সময় আটকে না থাকার মতো একটি মান নির্ধারণ করা ভালো।wait হলো অর্জনের অপেক্ষার ঊর্ধ্বসীমা। 0 হলে অসীম অপেক্ষা, অন্যথায় সেই সময়ের (সেকেন্ড) মধ্যে না পেলে সার্ভার হাল ছেড়ে দিয়ে T (টাইমআউট) দিয়ে সাড়া দেয় — কোনো grant ছাড়াই শেষ হয় বলে লক ফাঁস হওয়ার সুযোগ নেই।A সাড়ায় থাকা token হলো সেই grant-এর একঘেয়ে (monotonic) বর্ধনশীল u64। প্রতিটি অর্জনে আগের যেকোনো টোকেনের চেয়ে বড় মান ইস্যু করা হয়। ফেইলওভার ঘটলেও নতুন অ্যাক্টিভ হওয়া নোড রেপ্লিকেটেড সর্বোচ্চ টোকেনের চেয়ে বড় মান থেকে চালিয়ে যায় (উত্তরাধিকার) — তাই পুরো ক্লাস্টার জুড়ে হিসাব করলেও টোকেন সবসময় বাড়তে থাকে।
সুরক্ষিত করতে চাওয়া রিসোর্স (অ্যাকাউন্ট, ফাইল, অর্ডার ইত্যাদি) শুধু "এখন থাকা টোকেন সর্বশেষ দেখা টোকেনের চেয়ে বড় কিনা" যাচাই করলে, lease মেয়াদোত্তীর্ণ হওয়ার পর দেরিতে জেগে ওঠা ক্লায়েন্ট ইতিমধ্যে অকার্যকর হওয়া নিচু টোকেন দিয়ে অ্যাক্সেস করার চেষ্টা করলে তা প্রত্যাখ্যান করা যায়। এর ফলে লক সার্ভার প্রতি মুহূর্তে সম্পূর্ণ সামঞ্জস্যপূর্ণ না হলেও নিরাপত্তা বজায় রাখা সম্ভব।
অফিশিয়াল ক্লায়েন্টগুলো সাধারণভাবে নিম্নরূপ আচরণ করে (ভাষাভিত্তিক বিস্তারিত API-এর জন্য লাইব্রেরি দেখুন)।
lease পুনরুদ্ধার করবে, কিন্তু তার আগেই অন্য অপেক্ষমাণকে দ্রুত দেওয়ার জন্য)।peers তালিকার ক্রমই পদোন্নতির অগ্রাধিকার (সবচেয়ে সামনেরটি সর্বোচ্চ অগ্রাধিকার)। জীবিত নোডগুলোর মধ্যে সর্বোচ্চ অগ্রাধিকারসম্পন্ন একটি অ্যাক্টিভ হয়, বাকিরা সেই অবস্থার রিয়েল-টাইম রেপ্লিকেশন গ্রহণকারী স্ট্যান্ডবাই হয়।M) দিয়ে সেদিকে সরিয়ে দেওয়া হয়।Ctrl+C) হলে অ্যাক্টিভ আগে উত্তরসূরিকে পদোন্নতি হস্তান্তর করে (হ্যান্ডঅফ) তারপর ক্লায়েন্টকে রিডাইরেক্ট করে, ফলে অ্যাক্টিভ শূন্যতা ন্যূনতম হয়।এই পদোন্নতি পদ্ধতি কোরাম (সংখ্যাগরিষ্ঠ ভোট)-ভিত্তিক নয়। তাই জোড়/বিজোড় সংখ্যক সার্ভার গুরুত্বপূর্ণ নয়, এবং একটি সার্ভার জীবিত থাকলেই সেবা টিকে থাকে।
| সার্ভার সংখ্যা | নিরবচ্ছিন্নতা | একযোগে ব্যর্থতা সহনশীলতা | মন্তব্য |
|---|---|---|---|
| ১টি | ✗ | — | সবচেয়ে দ্রুত। পুনরায় চালু হওয়ার সময় সংক্ষিপ্ত বিচ্ছিন্নতা ঘটে |
| ২টি | ✓ | ১টি | নিরবচ্ছিন্নতার ন্যূনতম কনফিগারেশন। বেশিরভাগ ক্ষেত্রে এটিই যথেষ্ট |
| ৩টি | ✓ | ২টি | একটি রক্ষণাবেক্ষণের সময়েও দ্বৈততা বজায় থাকে |
| ৪টি+ | ✓ | N−১টি | শুধু প্রচারের খরচ বাড়ে — সুপারিশ করা হয় না |
অগ্রাধিকার-ভিত্তিক পদোন্নতি ঐক্যমত্য (consensus) নয়, তাই নেটওয়ার্ক পার্টিশনের মুহূর্তে উভয় পক্ষ সাময়িকভাবে একসাথে অ্যাক্টিভ হয়ে যেতে পারে, এবং অ্যাসিঙ্ক্রোনাস রেপ্লিকেশনের বৈশিষ্ট্যের কারণে ফেইলওভারের মুহূর্তে কিছু grant হারিয়ে যেতে পারে। অর্থাৎ ফেইলওভার/পার্টিশনের সময়ে পারস্পরিক বর্জন ১০০% নিশ্চিত করা হয় না। শক্তিশালী নিশ্চয়তা প্রয়োজন হলে আগে বর্ণিত ফেন্সিং টোকেন সুরক্ষিত রিসোর্স দিয়ে যাচাই করার ব্যবস্থা করুন — পুরনো (ছোট) টোকেন প্রত্যাখ্যান করলে লক সার্ভার সম্পূর্ণ সামঞ্জস্যপূর্ণ না হলেও নিরাপদ থাকে।