আপলোডে ভরসা করার আগে চূড়ান্ত FTP উত্তর যাচাই করুন

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

প্রাথমিক উত্তর বনাম চূড়ান্ত উত্তর

STOR-এর জন্য 125 বা 150 উত্তর প্রাথমিক। এটি বোঝায় সার্ভার চেষ্টা করতে রাজি এবং একটি ডেটা সংযোগ খুলছে, তবে অবজেক্টটি তার চূড়ান্ত রূপে আছে তা নয়। কাজটি সম্পূর্ণ হয় কেবল তখনই, যখন স্থানান্তর ওই কাজের প্রেক্ষাপটে একটি ইতিবাচক সমাপ্তি উত্তরে পৌঁছায়, সাধারণত 226 বা 250।

426 মানে স্থানান্তর বাতিল হয়েছে, আর অন্য কমান্ডের ছাপা কোনো সংখ্যা এই আপলোডের ফল নয়। STOR-এর নিজের উত্তর পড়ুন, স্ক্রিনের শেষ সংখ্যা নয়। ওই উত্তর আসার আগেই ক্লায়েন্ট বেরিয়ে গেলে সমাপ্তির কোনো প্রমাণই আপনার নেই।

নিয়ন্ত্রণ সংযোগ বনাম ডেটা সংযোগ

প্রমাণীকরণ ও ডিরেক্টরি তালিকা নিয়ন্ত্রণ সংযোগ ব্যবহার করে। বাইটগুলো ব্যবহার করে আলাদা একটি ডেটা সংযোগ, আর তার প্রান্তবিন্দু প্রতিটি স্থানান্তরের জন্য সমঝোতায় নির্ধারিত হয়। সফল লগইন নিয়ন্ত্রণ পথ প্রমাণ করে, কিন্তু ডেটা ঠিকানাটি ক্লায়েন্ট থেকে পৌঁছানো যায় কি না সে সম্পর্কে কিছুই বলে না।

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

TLS-এর উপর FTP বনাম SFTP

TLS-এর উপর FTP এখনও FTP: দুটি সংযোগ, FTP উত্তর, আর প্রতিটিতে TLS আপগ্রেড। SFTP হলো SSH-এর একটি সাবসিস্টেম—একটি সংযোগ আর সম্পূর্ণ ভিন্ন কমান্ড সেট। উদ্দেশ্য ছাড়া প্রায় কিছুই তারা ভাগ করে না, তাই তাদের মধ্যে ঘুরে বেড়ানো কোনো নির্ণয় সাধারণত ভুল লগ তুলনা করেই শুরু হয়।

মাঝখানের কোনো সহায়ক যন্ত্রকে সেশন দেখতে দেওয়ার জন্য TLS বন্ধ করবেন না, আর SFTP-এর ব্যর্থতাকে FTP উত্তরের সমস্যা ভাববেন না। curl ম্যানুয়াল স্ক্রিপ্টভিত্তিক পরীক্ষা দরকার হলে স্পষ্ট TLS, প্যাসিভ মোড ও আপলোড অপশন নথিভুক্ত করে, আর প্রতিটি ফ্ল্যাগ আসলে কী বদলায় তার তথ্যসূত্র এটি।

ডিবাগ করার আগে পরিষেবাটি আসলে যে প্রোটোকল দেয় সেটিই বেছে নিন। যে সার্ভার কেবল SFTP বলে, ক্লায়েন্ট যেভাবেই কনফিগার থাকুক, সে কখনো 226 উত্তর দেবে না।

দৃশ্যমান ফাইলনাম বনাম সংরক্ষিত অবজেক্ট

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

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

সাধারণ STOR বিদ্যমান ফাইল প্রতিস্থাপন করতে পারে, আর লগইন বা ডিরেক্টরি তালিকার অনুমতি সেখানে অবজেক্ট তৈরি বা প্রতিস্থাপনের অনুমতি প্রতিষ্ঠা করে না। পরীক্ষার জন্য আগে অব্যবহৃত দূরবর্তী নাম ব্যবহার করুন।

আবার চেষ্টার আগে কী তুলনা করবেন

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

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