অনুরোধটি সার্ভারে প্রেরণ করা হলে এবং প্রতিক্রিয়ার জন্য অপেক্ষা করার সময় ইন্টারনেট সংযোগ হারানো কী করবেন?


14

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


আমরা কত তথ্য নিয়ে কথা বলছি? গিগাবাইট?
ড্যানিয়েল হোলিনরাকে

খুব বেশি 7-8 এমবি নয়, তবে সার্ভারের প্রতিক্রিয়ার সময়টি অনেক দীর্ঘ এবং ফোন থেকে আপলোডের হার 128 কেবি / এস এর কাছাকাছি। আমি ডেটা আকারের কথা বলছি না তবে সংযোগ সমস্যার কথা বলছি।
mayank_droid 11

উত্তর:


15

এটি অ্যাসিক্রোনাস লেনদেনের ক্ষেত্রে মোটামুটি সাধারণ সমস্যা এবং বিভিন্ন অংশে পড়ে।

  1. উভয় পক্ষই কীভাবে জানবেন যে লেনদেনের অনুরোধটি সফলভাবে প্রাপ্ত হয়েছে?
  2. ক্লায়েন্টের বিশ্বাস যে সঠিকভাবে গৃহীত হয়নি এমন কোনও লেনদেনের অনুরোধ আপনি কীভাবে পুনরায় পাঠাতে পারেন?
  3. যখন সার্ভার সাফল্যের সাথে প্রথম অনুরোধটি পেয়েছে তখন ক্লায়েন্টের কাছ থেকে পুনরাবৃত্ত অনুরোধগুলি কীভাবে সনাক্ত করতে পারে?
  4. লেনদেনের ফলাফল কোথা থেকে পাবেন তা ক্লায়েন্ট কীভাবে জানতে পারে?

এইচটিটিপি সম্পর্কে দুর্দান্ত জিনিসটি হ'ল এই সমস্ত সমস্যার সমাধান করা মোটামুটি সহজ।

এর মতো একটি ইউআরএল কাঠামো কল্পনা করুন:

পোস্ট করুন http://my.server.com/application/engine/queue 
GET   http://my.server.com/application/engine/results?jobid=43425

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

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

শেষ ফলাফলটি হ'ল নেটওয়ার্কটি হারিয়ে গেলে এবং পুনরুদ্ধারকালে ক্লায়েন্ট সর্বদা একটি বুদ্ধিমান ব্যবস্থা করতে পারে এবং তেমনিভাবে সার্ভার সর্বদা ক্লায়েন্টের কাছ থেকে অনুরোধগুলি সংবেদনশীলভাবে প্রক্রিয়া করতে পারে


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

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

1
সেটিও পরিচালনা করা হয়। "প্রতিশ্রুতিবদ্ধ" লেনদেনটি ছোট এবং লেনদেন আইডি ব্যবহার করে, সুতরাং এটি ডেটা পুনঃপ্রেরণ না করে সস্তায় পুনরায় প্রকাশ করা যেতে পারে এবং সার্ভারটি হয় প্রক্রিয়াজাতকরণ শুরু করতে পারে, বা পূর্ববর্তী অনুরোধ থেকে ফলাফলটি ফিরিয়ে দিতে পারে। এটি আপনি যা পরামর্শ দিচ্ছেন তার সাথে খুব মিল; পার্থক্যটি হ'ল আমার কাছে চাকরির আইডি তৈরির জন্য আলাদা অনুরোধ রয়েছে, তাই আমার একটি অতিরিক্ত সিঙ্ক্রোনাইজেশন পয়েন্ট রয়েছে, তাই ক্লায়েন্ট জানতে পারে সম্পূর্ণ অনুরোধটি পুনরায় প্রেরণ না করেই কাজটি ইতিমধ্যে বিদ্যমান কিনা।
সাইমন রিখর

হ্যাঁ, এটা বোঝা যায়।
মাইকেল শ

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

4

এটি প্রোটোকল যোগাযোগের মূল বিষয়গুলির মধ্যে পড়ে। অ্যান্ড্রয়েড ক্লায়েন্ট দ্বারা একটি লেনদেনের জন্য অনুরোধ করা হয়েছে, এবং সার্ভারকে লেনদেনটি সম্পাদন করতে হবে। লেনদেন যদি এর থেকে অ্যান্ড্রয়েড ক্লায়েন্টের স্বীকৃতির উপর নির্ভর করে তবে এটি কল করা হবে এসি / এনএকে যোগাযোগ।

অন্যদিকে পক্ষের একটি অনুরোধের ফলাফল বলতে এসি (স্বীকৃতি) এবং নাক (নেতিবাচক-স্বীকৃতি) ব্যবহৃত হয়।

আপনি যা সম্পর্কে জিজ্ঞাসা করছেন তা হ'ল ক্লায়েন্ট এবং সার্ভারের মধ্যে একধরণের হ্যান্ডশেকিং এক্সচেঞ্জ এবং এটি একটি বেসিক এসি / এনএকে এক্সচেঞ্জের মাধ্যমে সম্পাদন করা যেতে পারে।

এখানে অ্যান্ড্রয়েডের দুটি উপায় স্বীকৃতি সহ কোনও ফাইল আপলোড করার একটি উদাহরণ।

Android -> upload files -> Server
Android <- ACK #id <- Server
Android -> ACK #id -> Server

উপরের উদাহরণে আমি #idলেনদেনের জন্য একটি অনন্য সনাক্তকারী যুক্ত করেছি । সার্ভারের ফাইলগুলি গ্রহণ করা উচিত, একটি লেনদেনের রেকর্ড তৈরি করা উচিত এবং এটিকে অ্যান্ড্রয়েডে প্রতিক্রিয়া হিসাবে প্রেরণ করা উচিত। তারপরে অ্যান্ড্রয়েডের সেই লেনদেনের স্বীকৃতি অনুসরণ করা উচিত (বা বিকল্পভাবে প্রত্যাখ্যানের জন্য একটি এনএকে)।

হ্যান্ডশেক করার সময় অ্যান্ড্রয়েড সংযোগ বিচ্ছিন্ন করার একটি উদাহরণ এখানে।

Android -> upload files -> Server
Android <- ACK #id <- Server
/** no ACK response **/

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

সার্ভার ধরে নিতে পারে যেহেতু ডিভাইসটি ACK দিয়ে সাড়া দেয় নি। অ্যান্ড্রয়েড ডিভাইসটি আপলোডটি সফল হয়েছে তা বোঝাতে এটির অভ্যন্তরীণ অবস্থা আপডেট করে নি। আমি লেনদেনটি বাতিল করে দেব এবং ভবিষ্যতে ডিভাইসটিকে পুনরাবৃত্তি করার অনুমতি দেব।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.