যে প্রোগ্রামগুলি ব্যর্থ ফাইল স্থানান্তর পুনরায় শুরু করতে পারে সেগুলি কীভাবে ডেটা সংযোজন শুরু করতে পারে?


23

কিছু ফাইল অনুলিপি প্রোগ্রামগুলির মতো rsyncএবং curlব্যর্থ স্থানান্তর / অনুলিপি পুনরায় চালু করার ক্ষমতা রাখে।

এই ব্যর্থতার অনেকগুলি কারণ থাকতে পারে তা উল্লেখ করে, কিছু ক্ষেত্রে প্রোগ্রাম "ক্লিনআপ" করতে পারে কিছু ক্ষেত্রে প্রোগ্রামটি পারে না।

যখন এই প্রোগ্রামগুলি আবার শুরু হয়, তারা মনে হয় কেবলমাত্র ফাইল / ডেটার আকারটি সফলভাবে স্থানান্তরিত হয়েছিল এবং উত্স থেকে পরবর্তী বাইটটি পড়া এবং ফাইল খণ্ডে যুক্ত করা শুরু করে।

উদাহরণস্বরূপ গন্তব্যে ফাইল তৈরির আকারটি এটি তৈরি করেছে 1378 বাইট, সুতরাং তারা কেবল আসলটি বাইট 1379 থেকে পড়া শুরু করতে এবং খণ্ডে যুক্ত করতে শুরু করে।

আমার প্রশ্নটি হ'ল বাইটস বিট দিয়ে গঠিত এবং সমস্ত ফাইলের ডেটাগুলি ক্লিন বাইট সাইজের অংশগুলিতে বিভক্ত থাকে না, এই প্রোগ্রামগুলি কীভাবে জানবে যে তারা সঠিকভাবে ডেটা যুক্ত করা শুরু করেছে তা ঠিক কী বিন্দুতে বেছে নিয়েছে?

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

সমস্ত ডেটা বাইট হিসাবে প্রতিনিধিত্ব করে না তা জেনেও এই অনুমানগুলি ভুল বলে মনে হয়।

যখন এই প্রোগ্রামগুলি "পুনরায় শুরু করুন" তারা কীভাবে জানবে যে তারা সঠিক জায়গায় শুরু করছে?


21
"সমস্ত ফাইলের ক্লিন বাইট সাইজের খণ্ডগুলিতে তাদের ডেটাগুলি সেগমেন্টযুক্ত থাকে না" তারা কি না? আপনি কীভাবে কোনও ফাইলে বাইটের চেয়ে কম কিছু লিখবেন?
মারু

17
আমি এমন কোনও সিস্টেম কল সম্পর্কে জানি না যা বাইটের চেয়ে কম কিছু লিখতে পারে এবং ডিস্কটি নিজেই মনে করি, কোনও ডিস্কই আজ 512 বাইট ব্লক (বা 4096 বাইট ব্লক) এর চেয়ে কম লিখেনি।
মারু

8
না, আমি বলছি সর্বনিম্ন একটি বাইট। বুদ্ধিমান অ্যাপ্লিকেশনগুলি 4KB বা 8KB খণ্ড ব্যবহার করবে: head -c 20480 /dev/zero | strace -e write tee foo >/dev/nullএবং তারপরে ওএস সেগুলি বাফার করবে এবং এটিকে আরও বড় অংশগুলিতে ডিস্কে প্রেরণ করবে।
মারু

9
@ থাই_ভালোয়ার_ফোগ: আপনি কীভাবে একটি বিট দিয়ে লিখবেন fwrite()?
শ্রদ্ধেয়

9
সব ব্যবহারিক উদ্দেশ্যে, তথ্য হয় বাইট গঠিত এবং সবকিছু ক্ষুদ্রতম ইউনিট হিসাবে তাদের সঙ্গে পরিচালনা করে। কিছু সিস্টেম (বেশিরভাগ সংক্ষেপণের সাথে সম্পর্কিত যেমন gzip, h264) বাইটগুলির বাইরে পৃথক বিটগুলি আনপ্যাক করে তবে অপারেটিং সিস্টেম এবং মেমরি অপারেশনটি বাইটের স্তরে থাকে।
pjc50

উত্তর:


40

স্পষ্টতার স্বার্থে - প্রকৃত যান্ত্রিকগুলি আরও ভাল সুরক্ষা দিতে আরও জটিল - আপনি লিখিত-থেকে-ডিস্কের অপারেশনটি কল্পনা করতে পারেন:

  • আবেদন লিখে বাইট (1)
  • কার্নেল (এবং / অথবা ফাইল সিস্টেম IOSS) তাদের বাফার করে
  • একবার বাফার পূর্ণ হয়ে গেলে এটি ফাইল সিস্টেমে ফ্লাশ হয়ে যায়:
    • ব্লক বরাদ্দ করা হয়েছে (2)
    • ব্লকটি লিখিত (3)
    • ফাইল এবং ব্লক তথ্য আপডেট করা হয়েছে (4)

যদি প্রক্রিয়াটি (1) এ বাধা পায়, আপনি ডিস্কে কিছু পান না, ফাইলটি অক্ষত এবং পূর্ববর্তী ব্লকে ছাঁটা হয়েছে। আপনি 5000 বাইট প্রেরণ করেছেন, কেবল 4096 ডিস্কে রয়েছে, আপনি 4096 অফসেটে স্থানান্তর পুনরায় চালু করবেন।

(2) এ থাকলে, স্মৃতি ছাড়া কিছুই হয় না। (1) হিসাবে একই। যদি (3) তে থাকে তবে ডেটা লেখা থাকলেও কেউ এ সম্পর্কে মনে রাখে না । আপনি 9000 বাইট প্রেরণ করেছেন, 4096 লিখেছেন, 4096 লিখেছেন এবং হারিয়েছেন , বাকি কেবল হারিয়ে গেছে। স্থানান্তর 4096 অফসেটে পুনরায় শুরু হয়।

(4) এ থাকলে ডেটা এখন ডিস্কে প্রতিশ্রুতিবদ্ধ হওয়া উচিত ছিল। স্ট্রিমের পরবর্তী বাইটগুলি হারিয়ে যেতে পারে। আপনি 9000 বাইট প্রেরণ করেছেন, 8192 লিখিত পেতে, বাকি হারিয়ে গেছে, অফসেট 8192 এ পুনরায় স্থানান্তর পুনরায় শুরু করুন।

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

বেশিরভাগ ফাইল সিস্টেম জার্নালিং বাস্তবায়ন করে , যাতে সবচেয়ে ঝুঁকিপূর্ণ বিন্দু (4) সত্যই দুর্বল না হয় তা নিশ্চিত করতে মেটা-ডেটা লিখে, আপনি এটি অনুমান করেছিলেন, লেনদেন যা পর্যায়ক্রমে যা ঘটবে তা ধারাবাহিকভাবে কাজ করবে (5)।

যদি কোনও লেনদেনের মাঝামাঝি সিস্টেমটি পুনরায় সেট হয়ে যায় তবে এটি নিকটতম অক্ষত চেকপয়েন্টে যাওয়ার পথটি আবার শুরু করতে পারে। লিখিত ডেটা এখনও হারিয়ে গেছে, কেস (1) এর মতো, তবে পুনরায় শুরু করা এটির যত্ন নেবে। কোন তথ্য আসলে হারিয়ে যায় না।


1
দুর্দান্ত ব্যাখ্যা। যে সমস্ত জ্ঞান অনেক তোলে। সুতরাং যদি কোনও প্রক্রিয়া এটিকে (4) ফাইল ব্লক তথ্য আপডেট করে তোলে, আপনি জানেন যে সমস্ত বাইট ভাল। তারপরে আগের কোনও পর্যায়ে থাকা কোনও বাইটগুলি এটি ডিস্কে তৈরি করে না বা - যদি তা করে থাকে - তবে তারা "
স্মরণবিহীন

4
@ থি_ভেলোর_ফগ এবং কেবলমাত্র পেনাল্টিমেট অনুচ্ছেদের পরিপূরক হিসাবে - আপনি যদি এমন একটি ফাইল সিস্টেম ব্যবহার করেন যা জার্নালিং বাস্তবায়ন করে না , আপনি অবশ্যই "ভাঙা" ডেটা পেতে পারেন, যার ফলে রেজ্যুম ব্যর্থ হয়ে যায় এবং আপনাকে ত্রুটি না দিয়েই গার্বল্ড ফাইল তৈরি করতে পারে । এটি অতীতে সর্বদা ঘটত, বিশেষত উচ্চ-ক্ষতিকারক ডিভাইসগুলির জন্য ডিজাইন করা ফাইল-সিস্টেমগুলির সাথে (ফ্লপিগুলির মতো)। ফাইল-সিস্টেমটি এইভাবে নির্ভরযোগ্য না হলেও এটি এড়ানোর জন্য এখনও কিছু কৌশল ছিল, তবে এটির ক্ষতিপূরণ দেওয়ার জন্য একটি স্মার্ট অ্যাপ্লিকেশন প্রয়োজন এবং কিছু অনুমান যা কিছু সিস্টেমে ভুল হতে পারে।
লুয়ান

এই উত্তরটি ফাইল সিস্টেমে জার্নালিংয়ের উপকারীতাকে বাড়াবাড়ি করে। যতক্ষণ না সবকিছু ইউজারস্পেস অ্যাপ্লিকেশন (মাধ্যমে fsync) এবং হার্ড ড্রাইভ নিয়ামক (প্রায়শই ভাঙা এমনকি এমনকী "এন্টারপ্রাইজ" ড্রাইভেও অন্তর্ভুক্ত থাকে) যতক্ষণ না সবকিছু লেনদেনমূলক শব্দার্থক প্রয়োগ করে তা নির্ভরযোগ্যভাবে কাজ করে না । fsyncঅনেকগুলি ফাইল অপারেশন ছাড়াই স্বজ্ঞাত অর্ডার করা হয় এবং পারমাণবিকটি পসআইএক্সের দ্বারা এমনটি হওয়ার নিশ্চয়তা দেয় না : ফাইলগুলি খোলা থাকে যার সাথে ফাইলগুলি খোলা O_APPENDথাকে না etc. ইত্যাদি ছাড়া অনুশীলনের ক্ষেত্রে ফাইলের ধারাবাহিকতার জন্য গুরুত্বপূর্ণ কীগুলি হ'ল কার্নেল ভিএফএস সিস্টেম এবং ডিস্ক ক্যাশে। অন্য সব কিছুই বেশিরভাগই ফ্লফ।
ব্যবহারকারী1643723

11

দ্রষ্টব্য: আমি উত্স rsyncবা অন্য কোনও ফাইল স্থানান্তর ইউটিলিটির দিকে নজর দিইনি।

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

উভয় ক্রিয়াকলাপ স্ট্যান্ডার্ড সি লাইব্রেরি ফাংশনে একক কল দিয়ে সম্পন্ন হয় lseek()( lseek(fd, 0, SEEK_END)ফাইলের বর্ণনাকারীর জন্য খোলা ফাইলটির দৈর্ঘ্য fd, বাইটগুলিতে পরিমাপ করে) প্রদান করে।

একবার যে লক্ষ্য ফাইলের জন্য সম্পন্ন হলে, একটি অনুরূপ কলে lseek()উপযুক্ত অবস্থানে ঝাঁপ সোর্স ফাইল সম্পন্ন করা যেতে পারে: lseek(fd, pos, SEEK_SET)। উত্স ফাইলটির পূর্ববর্তী অংশটি অপরিবর্তিত হিসাবে চিহ্নিত করা হয়েছে (ধরে নেওয়া যায় না যে পৃথক ইউটিলিটিগুলি বিভিন্ন উপায়ে এটি করতে পারে) ধরে নেওয়া যায় point

একটি ফাইল ডিস্কে খণ্ডিত হতে পারে তবে ফাইল সিস্টেমটি নিশ্চিত করবে যে কোনও অ্যাপ্লিকেশন ফাইলটিকে বাইটের অনুক্রমিক ক্রম হিসাবে অনুধাবন করবে।


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

কোনও ফাইলে একক বিট লেখা সম্ভব নয় এবং যদি কোনও রাইটিং অপারেশন ব্যর্থ হয় তবে এটি ফাইলটিতে "অর্ধ-লিখিত বাইট" ছাড়বে না।


ধন্যবাদ, সুতরাং এটি কোনটি নিশ্চিত করে যে কোনও লিখন অপারেশন ব্যর্থ হয় - এটি অর্ধেক লিখিত বাইট ছেড়ে যাবে না? এটি কি কর্নেল বাফারিং মুড়ু বর্ণনা করছে? - যেমন কার্নেলে 8KB অংশ পাঠানোর মাঝে যদি কোনও প্রক্রিয়া বাধাগ্রস্ত হয় এবং অপ্রত্যাশিতভাবে বন্ধ হয়ে যায় - 8KB অংশটি কখনই কার্নেলে পৌঁছতে পারে না - তবে কার্নেল এবং ফাইল সিস্টেমের কাছে পৌঁছানো পূর্ববর্তী কোনওটি ভাল বলে ধরে নেওয়া যেতে পারে?
the_velour_fog

6
@ এটি_ভালোয়ার_ফোগ এই ধরণের অপ্রত্যাশিত অবসান ঘটতে পারে না, কারণ প্রক্রিয়াটি আই / ও সিস্টেম কলের মাঝখানে অবিচ্ছিন্ন হবে (এ কারণেই এনএফএস ফাইলের জন্য ফাইল সিস্টেম অ্যাক্সেস কলগুলিতে অদৃশ্য প্রক্রিয়া আটকে থাকা অস্বাভাবিক নয়)। এছাড়াও দেখুন: unix.stackexchange.com/q/62697/70524
muru

2
সঠিক সময়ে সিস্টেমটি ক্ষমতা হারিয়ে ফেললে সমস্যা হতে পারে। এটি মাঝেমধ্যে কোনও ফাইলের শেষ রাইটিং পয়েন্টে আবর্জনা ফেলতে পারে। এটি ডাটাবেস ডিজাইনের একটি খুব জটিল সমস্যা। তবে এখনও সাধারণ ক্ষুদ্রতম ইউনিট যা হয় "বৈধ" বা "অবৈধ" হয় এটি একটি ডিস্ক ব্লক।
pjc50

1
@the_velour_fog এটি " অর্ধ লিখিত বাইট " (বা আরও সঠিকভাবে, বাইটের অর্ধ-লিখিত ব্লক ) পেতে না পারার মতো এটি অর্ধ-লিখিত ব্লকটি লিখিত হয়েছে বলে রেকর্ড করা হবে না (পুরোপুরিভাবে ) - এলসার্নির উত্তরের পদক্ষেপ (3) এবং (4) দেখুন ।
ট্রিপহাউন্ড

5

এটি মূলত দুটি প্রশ্ন, কারণ কার্ল এবং rsync এর মতো প্রোগ্রামগুলি খুব আলাদা।

কার্টের মতো এইচটিটিপি ক্লায়েন্টদের জন্য তারা বর্তমান ফাইলের আকার চেক করে এবং তারপরে Content-Rangeঅনুরোধ সহ একটি শিরোনাম প্রেরণ করে । সার্ভার হয় (সাফল্যের 206) পরিবর্তে স্থিতি কোড (আংশিক সামগ্রী) ব্যবহার করে ফাইলের পরিসর পাঠানো পুনরায় শুরু করে 200এবং ডাউনলোডটি আবার শুরু করা হয় অথবা এটি শিরোনামকে উপেক্ষা করে শুরু থেকে শুরু হয় এবং এইচটিটিপি ক্লায়েন্টের কাছে সমস্ত কিছুই পুনরায় ডাউনলোড করা ছাড়া অন্য কোনও পছন্দ নেই আবার।

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

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

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

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

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


4

টিএল; ডিআর: তারা যে প্রোটোকল ব্যবহার করে তা এটির অনুমতি না দিলে তারা পারবেন না।

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

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

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

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


আরএসআইএনসি উদাহরণের জন্য, এটি সোজা হতে চলেছে কারণ এখানে কেবল একটি আরএসএনসি প্রোটোকল রয়েছে। HTTP ডাউনলোডের জন্য, মান হিসাবে সীমা-অনুরোধ রয়েছে। পুনঃসূচনা-আপলোডের ক্ষেত্রে কার্লটি আসলে কী করে তা জানার জন্য আমি আগ্রহী, কারণ আপলোডের মানক শব্দার্থবিজ্ঞানগুলি মাল্টিপার্ট / ফর্ম-ডেটা (উইজেট এবং কার্লের জন্য) তবে আমি বিশ্বাস করি না যে আপলোড পুনঃসূচনা শব্দার্থকগুলি সর্বজনীনভাবে একমত হয়েছে। YouTube এবং Nginx উদাহরণস্বরূপ এটি আলাদাভাবে করতে পারে।
রব

1

স্থানান্তর করতে ব্যবহৃত প্রোটোকলের উপর নির্ভর করে। তবে কার্ল HTTP ব্যবহার করে এবং এটি ফাইলটিতে প্রদর্শিত ক্রম হিসাবে এটি ক্রমাগত ডেটা স্থানান্তর করে। সুতরাং কার্ল আংশিকভাবে সম্পন্ন স্থানান্তর ফাইলের আকারের ভিত্তিতে পুনরায় শুরু করতে পারে। প্রকৃতপক্ষে, আপনি দৈর্ঘ্যের এন (যে কোনও একটি) ফাইল তৈরি করে এবং সেই ফাইলটিকে আংশিকভাবে সমাপ্ত ডাউনলোড হিসাবে গণ্য করতে (এবং তারপরে প্রথম এন বাইটগুলি ত্যাগ করে) প্রথম এন বাইটস এড়িয়ে চলাতে পারেন।

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