প্ৰক্সি কৰা WebSocket পুনৰ সংযোগৰ পিছত, ছেছনো পুনৰুদ্ধাৰ কৰক

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

একে প্ৰক্সি এণ্ডপইণ্টেও এটা নতুন বাহ্যিক সংযোগ উৎপন্ন কৰিব পাৰে। সলনি হোৱা এক্সিট IP-এ গন্তব্যস্থানৰ নিজৰ ছেছন নীতি সক্ৰিয় কৰিব পাৰে। নতুন ছকেটক নতুন সংযোগ হিচাপে গণ্য কৰক আৰু এপ্লিকেচনৰ নথিভুক্ত পুনৰুদ্ধাৰ বিনিময় অনুসৰণ কৰক। পুনৰ সংযোগ কৰোঁতে ৱৰ্কফ্ল'ৱে ইয়াৰ প্ৰক্সি পথ ৰখা উচিত নেকি সিদ্ধান্ত ল'ব।

শেষ URL-তকৈ অলপ বেছি ৰাখক

উপযোগী পুনৰুদ্ধাৰ অৱস্থাত অনুমোদিত ছেছন পৰিচয়, ইচ্ছাকৃত চাবস্ক্ৰিপচন, শেষ নিশ্চিত কৰা ইভেণ্ট আইডেণ্টিফায়াৰ আৰু স্বীকৃতিৰ বাবে বাকী থকা কাৰ্য্য থাকিব পাৰে। সেই ক্ষেত্ৰসমূহ এপ্লিকেচন প্ৰ'ট'কলৰ; WebSocket-এ সাৰ্বজনীন ৰিজিউম টোকেন সংজ্ঞায়িত নকৰে।

কাৰ্ছৰৰ পৰা ৰিজিউম কৰিব নে, নতুন স্নেপশ্বট ল'ব নে, নে ব্যৱধান গ্ৰহণ কৰিব সেই সিদ্ধান্ত ল'ব। যদি ইভেণ্ট উৎসই ৰিপ্লে ইণ্টাৰফেচ নিদিয়ে, তেন্তে বেগাই পুনৰ সংযোগ কৰিলে কোনো বাৰ্তা হেৰোৱা নাই বুলি প্ৰমাণ কৰিব নোৱাৰে।

দুবাৰ পঠিয়ালে দুবাৰ কৰা হ'ব পাৰে

সংযোগ বিচ্ছিন্ন হোৱাৰ আগতে স্থানীয়ভাৱে শাৰীত ৰখা বাৰ্তা হয়তো ক্লায়েণ্টৰ পৰা ওলাই নাযায়। আন এটা বাৰ্তাই হয়তো ছাৰ্ভাৰ পাইছিল কিন্তু তাৰ স্বীকৃতি হেৰাইছিল। নিশ্চিত নোহোৱা প্ৰতিটো আদেশ অন্ধভাৱে পুনৰ পঠিয়ালে এই দুয়োটা অৱস্থাক একে বুলি ধৰা হয়।

য'ত উপলব্ধ তাত সেৱাৰ অনুৰোধ আইডেণ্টিফায়াৰ, ইডেম্পটেন্সি সমৰ্থন বা মিলন ব্যৱস্থা ব্যৱহাৰ কৰক। পৰিবহনৰ পুনৰ সংযোগে এপ্লিকেচনৰ কাৰ্য্য বিপৰীতমুখী কৰিব নোৱাৰে বা স্বয়ংক্ৰিয়ভাৱে নকল আঁতৰাব নোৱাৰে।

পুনৰ সংযোগৰ প্ৰচেষ্টা সীমিত ৰাখক আৰু এপ্লিকেচনৰ নীতি অনুসৰি গতি নিয়ন্ত্ৰণ কৰক। RFC 6455-এ অস্বাভাৱিক বন্ধৰ পিছত বেকঅফৰ পৰামৰ্শ দিয়ে; লগে লগে পুনৰ চেষ্টা কৰা ক্লায়েণ্টৰ সমূহে বিভ্ৰাটৰ চাপ বঢ়াব পাৰে।

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