আপনার গেটওয়ে যে FTP প্রক্সি লগইন পদ্ধতি আশা করে তা বেছে নিন
একটি নেটিভ FTP গেটওয়ের USER, SITE বা OPEN কথোপকথনকে এমন একটি ক্লায়েন্টের সঙ্গে মেলান যা তা সমর্থন করে, গেটওয়ে অ্যাকাউন্টটি লক্ষ্য অ্যাকাউন্ট থেকে আলাদা রেখে।
“FTP প্রক্সি” এমন একটি গেটওয়ে বোঝাতে পারে যা নিজেই FTP বলে। এতে সংযোগ করা HTTP প্রক্সিকে CONNECT চাওয়া বা SOCKS সার্ভারকে TCP গন্তব্য খুলতে বলার থেকে আলাদা।
গেটওয়ের লক্ষ্য হোস্ট ও অ্যাকাউন্ট দরকার, এবং প্রথমে তার নিজের লগইনও লাগতে পারে। পণ্যগুলো সেই কথোপকথন বিভিন্নভাবে প্রকাশ করে:
| বিন্যাস | সাধারণ কমান্ডের রূপ |
|---|---|
| ব্যবহারকারীনামে লক্ষ্য এনকোড করা | USER target-user@target-host |
| আলাদা গেটওয়ে লগইন | গেটওয়ে USER/PASS, তারপর লক্ষ্যের লগইন |
| স্পষ্ট গন্তব্য কমান্ড | SITE target-host বা OPEN target-host, তারপর প্রয়োজনীয় লগইন |
এগুলো রীতির পরিবার, প্রতিটি গেটওয়েতে পাঠানোর একক মানক ক্রম নয়। প্রশাসক যে পদ্ধতি নথিভুক্ত করেছেন এবং ক্লায়েন্ট যে সমর্থন করে সেটিই বেছে নিন।
সেটআপে দুটি অ্যাকাউন্টই দৃশ্যমান রাখুন
লক্ষ্যের FTP পাসওয়ার্ড ও গেটওয়ের পাসওয়ার্ড আলাদা হতে পারে। কিছু গেটওয়ে সেগুলো এক USER/PASS রূপে মেলায়; অন্যরা আলাদা বিনিময় চায়। সব মান একটি স্ট্রিংয়ে রাখলে এমন ক্লায়েন্ট পুনরুৎপাদন হয় না যাকে অতিরিক্ত কমান্ড পাঠাতে হয়।
এটি পুরোনো FtpWebRequest কোডে একটি উপকারী সীমা ব্যাখ্যা করে। গেটওয়েতে একটি সাধারণ FTP সংযোগ, গেটওয়ে-নির্দিষ্ট ব্যবহারকারীনামসহ, কিছু USER/PASS বিন্যাসে মানাতে পারে। আলাদা SITE বা OPEN কথোপকথন দরকার এমন গেটওয়ের জন্য এমন ক্লায়েন্ট লাগে যা সত্যিই সেই প্রবাহ সমর্থন করে। WebRequest-এর Proxy বৈশিষ্ট্য আবার অন্য একটি ইন্টারফেস।
উদাহরণস্বরূপ WinSCP সব গেটওয়েকে একক হোস্ট ফিল্ড হিসেবে না দেখে আলাদা FTP প্রক্সি লগইন পদ্ধতি প্রকাশ করে। এর সংখ্যাগত কাঁচা সেটিং মান এর নথিভুক্ত API-র অন্তর্গত; কনফিগারেশন পর্যালোচনার সময় পদ্ধতির নাম ও অভীষ্ট কথোপকথন ব্যবহার করুন।
লগইনের পরেও ফাইল স্থানান্তরের জন্য FTP ডেটা সংযোগ ও নির্বাচিত TLS মোড দরকার। নিয়ন্ত্রণ চ্যানেলে সফল লগইন সেই পথের সূচনা, প্রতিটি ডেটা স্থানান্তর ইতিমধ্যেই অনুমোদিত এর প্রমাণ নয়।