প্রক্সি করা WebSocket পুনঃসংযোগের পরে সেশনও পুনরুদ্ধার করুন

পুনঃসংযোগ কলব্যাক চলে এবং নতুন সকেট খোলে। এটি পরিবহনের পুনরুদ্ধার। এর অর্থ এই নয় যে আপনার সাবস্ক্রিপশন, বার্তা স্বীকৃতি বা অ্যাপ্লিকেশন সেশন আগের সংযোগ যেখানে থেমেছিল সেখান থেকেই চলেছে।

একই প্রক্সি এন্ডপয়েন্টও একটি নতুন বহির্গামী সংযোগ তৈরি করতে পারে। পরিবর্তিত এক্সিট IP গন্তব্যের নিজস্ব সেশন নীতি সক্রিয় করতে পারে। নতুন সকেটকে নতুন সংযোগ হিসেবে গণ্য করুন এবং অ্যাপ্লিকেশনের নথিভুক্ত পুনরুদ্ধার বিনিময় অনুসরণ করুন। পুনঃসংযোগের সময় ওয়ার্কফ্লো তার প্রক্সি পথ ধরে রাখা উচিত কি না তা ঠিক করুন।

শেষ URL-এর চেয়ে একটু বেশি রাখুন

উপযোগী পুনরুদ্ধার অবস্থায় অনুমোদিত সেশন পরিচয়, কাঙ্ক্ষিত সাবস্ক্রিপশন, সর্বশেষ নিশ্চিত ইভেন্ট শনাক্তকারী এবং স্বীকৃতির অপেক্ষায় থাকা কার্যক্রম থাকতে পারে। এই ক্ষেত্রগুলি অ্যাপ্লিকেশন প্রোটোকলের; WebSocket কোনো সর্বজনীন রিজিউম টোকেন সংজ্ঞায়িত করে না।

কার্সর থেকে পুনরায় শুরু করবেন, নতুন স্ন্যাপশট নেবেন, নাকি ফাঁক মেনে নেবেন তা ঠিক করুন। যদি ইভেন্ট উৎস কোনো রিপ্লে ইন্টারফেস না দেয়, তবে দ্রুত পুনঃসংযোগ করলে কোনো বার্তা বাদ পড়েনি তা প্রমাণ করা যায় না।

দুবার পাঠানো মানে দুবার করা হতে পারে

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

যেখানে পাওয়া যায় সেখানে পরিষেবার অনুরোধ শনাক্তকারী, ইডেম্পোটেন্সি সমর্থন বা মিলন ব্যবস্থা ব্যবহার করুন। পরিবহনের পুনঃসংযোগ কোনো অ্যাপ্লিকেশন কাজকে বিপরীতমুখী করতে পারে না বা স্বয়ংক্রিয়ভাবে তার নকল সরাতে পারে না।

পুনঃসংযোগের চেষ্টা সীমিত রাখুন এবং অ্যাপ্লিকেশনের নীতি অনুযায়ী গতি ঠিক করুন। RFC 6455 অস্বাভাবিক বন্ধের পরে ব্যাকঅফের পরামর্শ দেয়; একসঙ্গে সঙ্গে পুনরায় চেষ্টা করা ক্লায়েন্টদের ভিড় বিভ্রাটের চাপ বাড়াতে পারে।

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