FTP
Protokol pengiriman berkas (bahasa Inggris: File Transfer Protocol) adalah sebuah protokol Internet yang berjalan di dalam lapisan aplikasi yang merupakan standar untuk pengiriman berkas (file) komputer antar mesin-mesin dalam sebuah Antarjaringan.
FTP merupakan salah satu protokol Internet yang paling awal dikembangkan, dan masih digunakan hingga saat ini untuk melakukan pengunduhan (download) dan penggugahan (upload) berkas-berkas komputer antara klien FTP dan server FTP. Sebuah Klien FTP merupakan aplikasi yang dapat mengeluarkan perintah-perintah FTP ke sebuah server FTP, sementara server FTP adalah sebuah Windows Service atau daemon yang berjalan di atas sebuah komputer yang merespons perintah-perintah dari sebuah klien FTP. Perintah-perintah FTP dapat digunakan untuk mengubah direktori, mengubah modus pengiriman antara biner dan ASCII, menggugah berkas komputer ke server FTP, serta mengunduh berkas dari server FTP.
Sebuah server FTP diakses dengan menggunakan Universal Resource Identifier (URI) dengan menggunakan format ftp://namaserver. Klien FTP dapat menghubungi server FTP dengan membuka URI tersebut.
FTP menggunakan protokol Transmission Control Protocol (TCP) untuk komunikasi data antara klien dan server, sehingga di antara kedua komponen tersebut akan dibuatlah sebuah sesi komunikasi sebelum pengiriman data dimulai. Sebelum membuat koneksi, port TCP nomor 21 di sisi server akan "mendengarkan" percobaan koneksi dari sebuah klien FTP dan kemudian akan digunakan sebagai port pengatur (control port) untuk (1) membuat sebuah koneksi antara klien dan server, (2) untuk mengizinkan klien untuk mengirimkan sebuah perintah FTP kepada server dan juga (3) mengembalikan respons server ke perintah tersebut. Sekali koneksi kontrol telah dibuat, maka server akan mulai membuka port TCP nomor 20 untuk membentuk sebuah koneksi baru dengan klien untuk mengirim data aktual yang sedang dipertukarkan saat melakukan pengunduhan dan penggugahan.
FTP hanya menggunakan metode autentikasi standar, yakni menggunakan username dan password yang dikirim dalam bentuk tidak terenkripsi. Pengguna terdaftar dapat menggunakan username dan password-nya untuk mengakses, men-download, dan meng-upload berkas-berkas yang ia kehendaki. Umumnya, para pengguna terdaftar memiliki akses penuh terhadap beberapa direktori, sehingga mereka dapat membuat berkas, membuat direktori, dan bahkan menghapus berkas. Pengguna yang belum terdaftar dapat juga menggunakan metode anonymous login, yakni dengan menggunakan nama pengguna anonymous dan password yang diisi dengan menggunakan alamat e-mail.
Seperti yang anda ketahui bahwa FTP (File Transfer Protocol) adalah salah satu protokol paling populer yang digunakan untuk mengirim atau menerima (transfer) file antara komputer lokal dengan komputer server. Untuk dapat menjalankan FTP, anda harus menginstall aplikasi FTP seperti VSFTPD di server anda dan juga menginstall aplikasi FTP Client seperti Filezilla di komputer lokal anda terlebih dahulu. Namun dalam artikel ini yang akan dibahas adalah cara install dan konfigurasi FTP di dalam server dengan menggunakan aplikasi VSFTPD.
Berikut adalah cara install dan konfigurasi FTP server di ubuntu dengan menggunakan aplikasi VSFTPD :
Karena vsftpd sudah tersedia secara default di repositories ubuntu, maka untuk menginstallnya anda hanya perlu memberikan perintah :
sudo apt-get install vsftpd
Setelah proses instalasi VSFTPD selesai, selanjutnya lakukan konfigurasi VSFTPD dengan cara sebagi berikut :
Buka file konfigurasi VSFTPD default yang terdapat di /etc/vsftpd.conf dengan menggunakan editor pilihan anda. Kali ini saya menggunakan nano editor (Baca: cara install nano editor).
sudo nano /etc/vsftpd.conf
Disable anonymous untuk mencegah anonymous user berhasil login. Pastikan tidak ada tanda pagar sebelum :
anonymous_enable=NO
Dan pastikan tidak terdapat YES disana.
Untuk mempermudah pencarian, anda bisa gunakan CTRL+W dan masukan barisan kata atau kalimat konfigurasi yang anda inginkan.
Selanjutnya anda harus mengaktifkan (enable) login user yang menggunakan file otentikasi lokal dengan menghilangkan tanda pagar sebelum :
local_enable=YES
Supaya user dapat melakukan modifikasi file system, anda perlu menghilangkan tanda pagar juga sebelum :
write_enable=YES
Jika anda ingin user anda hanya dapat mengakses direktori mereka sendiri, anda juga perlu menghilangkan tanda pagar sebelum :
chroot_local_user=YES
Langkah berikutnya adalah membuat user dan direktori user sebagai berikut :
Membuat user baru :
sudo adduser owen
Ganti owen dengan user yang anda inginkan. Anda akan diminta untuk membuat password dan mengisi beberapa data yang diminta. Untuk datanya bisa anda kosongkan dengan klik enter.
Mengatur kepemilikan (ownership) root pada direktori home owen :
sudo chown root:root /home/owen\
Buatlah direktori baru di dalam home yang nantinya akan digunakan untuk menyimpan file-file yang akan diupload :
sudo mkdir /home/owen/www
Terakhir, silahkan berikan hak akses direktori tersebut ke user yang sudah anda buat tadi :
sudo chown owen:owen /home/owen/www
Proses instalasi dan konfigurasi FTP server di linux ubuntu sudah selesai. Selanjutnya anda bisa mengaksesnya melalui terminal konsol atau dengan menggunakan FTP client pihak ketiga seperti filezilla dengan port default 21 (Baca : cara menggunakan filezilla). Selain itu, anda juga dapat melihat atau mengakses file yang telah anda upload dengan mengetikan ftp://IP atau ftp://domain.com di browser pilihan anda.
SAMBA
File Server memberikan layanan berupa penyediaaan file ataupun folder yang dapat diakses bersama-sama oleh para pengguna di dalam suatu jaringan. File Server sering juga disebut sebagai sistem File Sharing. Keuntungan dari penggunaan File Server ini dapat kalian lihat dari segi keefisiensiannya. Misalnya dalam suatu kasus kalian mempunyai 200 PC Client yang perlu diinstallkan program. Akan tetapi file installer program tersebut hanyamterdapat disalah satu komputer saja. Tentunya akan sangat merepotkan dan beresiko apabila kalian harus mengkopikan file installer tersebut ke tiap-tiap PC secara manual. Nah, solusinya adalah dengan penggunaan metode File Sharing ini. Dimana hanya ada satu komputer yang men-sharing file installer program tadi, lalu dari komputer-komputer client hanya tinggal mengaksesnya saja.
Samba adalah program yang bersifat open source yang menyediakan layanan berbagi berkas (file service) dan berbagi alat pencetak (print service), resolusi nama NetBIOS, dan pengumuman layanan (NetBIOS service announcement/browsing). Sebagai sebuah aplikasi file server, Samba mengizinkan berkas, alat pencetak, dan beberapa sumber daya lainnya agar dapat digunakan oleh banyak pengguna dalam keluarga sistem operasi UNIX, dan mengizinkan interoperabilitas dengan sistem operasi Windows. Samba dibuat berdasarkan protokol Server Message Block (SMB), oleh Andrew Tridgell.
Berikut langkahnya:
1. Install samba dengan perintah #apt-get install samba
2. Masuk ke file /etc/samba/smb.conf dengan cara #nano /etc/samba/smb.conf
3. Edit file seperti gambar berikut.
4. Setelah tersimpan silahkan anda masukan user untuk penguna samba jika anda mengunakan user dengan perintah #smbpasswd -a aku
5. Restart samba, dengan perintah #service samba restart
6. Setelah itu coba pada client windows dengan menekan windows + r muncul kotak dialog masukan \\ipserver atau \\192.168.137.2
7. Setelah diklik maka akan muncul kotak dialog untuk memasukan username dan password yang sudah di konfigurasikan tadi silahkan log in
Berikut ada RFC FTP versi Bahasa Indonesia:
Jaringan Kelompok Kerja J. Postel
Permintaan Komentar: 959 J. Reynolds
ISI
Obsoletes RFC: 765 (IEN 149) Oktober 1985
FILE TRANSFER PROTOCOL (FTP)
Status Memo ini
memo ini adalah spesifikasi resmi dari File Transfer
Protocol (FTP). Distribusi memo ini tidak terbatas.
mengikuti perintah opsional baru termasuk dalam edisi ini
spesifikasi:
CDUP (Ubah ke direktori Parent), SMNT (Struktur Mount), Stou
(Toko Unik), RMD (Hapus Direktori), MKD (Membuat Directory), PWD
(Direktori Cetak), dan SYST (System).
Perhatikan bahwa spesifikasi ini kompatibel dengan edisi sebelumnya.
1. PERKENALAN
Tujuan dari FTP adalah 1) untuk mempromosikan berbagi file (komputer
program dan / atau data), 2) untuk mendorong langsung atau implisit (via
program) penggunaan komputer remote, 3) untuk melindungi pengguna dari
variasi dalam sistem penyimpanan file antara host, dan 4) untuk mentransfer
Data andal dan efisien. FTP, meskipun dapat digunakan langsung oleh pengguna
di terminal, dirancang terutama untuk digunakan oleh program.
Upaya dalam spesifikasi ini adalah untuk memenuhi beragam kebutuhan
pengguna maxi-host, mini-host, workstation personal, dan TAC,
dengan sederhana, dan mudah diimplementasikan desain protokol.
Makalah ini mengasumsikan pengetahuan tentang Transmission Control Protocol
(TCP) [2] dan Protokol Telnet [3]. Dokumen-dokumen ini terkandung
dalam buku pegangan protokol ARPA-Internet [1].
2. GAMBARAN
Pada bagian ini, sejarah, terminologi, dan model FTP yang
dibahas. Ketentuan yang ditetapkan dalam bagian ini hanya orang-orang yang
memiliki arti khusus di FTP. Beberapa terminologi sangat
khusus untuk model FTP; beberapa pembaca mungkin ingin beralih ke
Bagian pada model FTP saat meninjau terminologi.
Postel & Reynolds [Halaman 1]
RFC 959 Oktober 1985
File Transfer Protocol
2.1. SEJARAH
FTP telah memiliki evolusi yang panjang selama bertahun-tahun. Lampiran III adalah
kompilasi kronologis Permintaan Komentar dokumen
berkaitan dengan FTP. Ini termasuk transfer file pertama kali diusulkan
mekanisme pada tahun 1971 yang dikembangkan untuk implementasi pada host
di M.I.T. (RFC 114), ditambah komentar dan diskusi dalam RFC 141.
RFC 172 tersedia protokol berorientasi user-level untuk transfer file
antara komputer host (termasuk terminal IMPS). Sebuah revisi
ini sebagai RFC 265, disajikan kembali FTP untuk ditinjau tambahan, sementara RFC 281
menyarankan perubahan lebih lanjut. Penggunaan "Set Data Type"
transaksi diusulkan pada RFC 294 pada Januari 1982.
RFC 354 RFC sudah usang 264 dan 265. File Transfer Protocol
sekarang didefinisikan sebagai protokol untuk transfer file antara host pada
ARPANET, dengan fungsi utama dari FTP didefinisikan sebagai
mentransfer file secara efisien dan andal antara host dan
memungkinkan penggunaan yang mudah dari kemampuan penyimpanan file jarak jauh.
RFC 385 lebih lanjut berkomentar pada kesalahan, poin penekanan, dan
penambahan protokol, sementara RFC 414 memberikan laporan status
pada server dan pengguna FTPs bekerja. RFC 430, yang diterbitkan pada tahun 1973,
(Antara RFC lain terlalu banyak untuk disebutkan) disajikan lebih lanjut
komentar di FTP. Akhirnya, "resmi" dokumen FTP adalah
diterbitkan sebagai RFC 454.
Pada bulan Juli 1973, perubahan besar dari versi terakhir dari FTP
yang dibuat, namun struktur umum tetap sama. RFC 542
diterbitkan sebagai "resmi" spesifikasi baru untuk mencerminkan ini
perubahan. Namun, banyak implementasi berdasarkan tua
spesifikasi tidak diperbarui.
Pada tahun 1974, RFC 607 dan 614 terus komentar pada FTP. RFC 624
diusulkan perubahan desain lebih lanjut dan modifikasi kecil. Pada tahun 1975,
RFC 686 yang berjudul, "Meninggalkan Nah Cukup Alone", membahas
perbedaan antara semua versi awal dan kemudian FTP.
RFC 691 disajikan revisi minor dari RFC 686, mengenai
subjek mencetak file.
Termotivasi oleh transisi dari NCP ke TCP sebagai
protokol yang mendasari, phoenix lahir dari semua di atas
upaya dalam RFC 765 sebagai spesifikasi FTP untuk digunakan pada TCP.
Edisi saat ini spesifikasi FTP dimaksudkan untuk
memperbaiki beberapa kesalahan dokumentasi kecil, untuk meningkatkan
penjelasan beberapa fitur protokol, dan menambahkan beberapa baru
perintah opsional.
Postel & Reynolds [Halaman 2]
RFC 959 Oktober 1985
File Transfer Protocol
Secara khusus, mengikuti perintah opsional baru termasuk dalam
edisi ini spesifikasi:
CDUP - Ubah ke direktori Parent
SMNT - Struktur Mount
Stou - Toko Unik
RMD - Hapus Direktori
MKD - Membuat Direktori
PWD - Direktori Cetak
SYST - Sistem
spesifikasi ini kompatibel dengan edisi sebelumnya. SEBUAH
Program dilaksanakan di kesesuaian dengan spesifikasi sebelumnya
secara otomatis berada dalam kesesuaian dengan spesifikasi ini.
2.2. TERMINOLOGI
ASCII
Set karakter ASCII sebagaimana didefinisikan dalam ARPA-Internet
Protokol Handbook. Dalam FTP, karakter ASCII didefinisikan sebagai
bagian bawah kode set delapan-bit (yaitu, paling
bit signifikan adalah nol).
kontrol akses
kontrol akses menentukan hak akses pengguna ke penggunaan
sistem, dan file dalam sistem itu. Akses kontrol yang
diperlukan untuk mencegah penggunaan yang tidak sah atau file tanpa disengaja.
Ini adalah hak prerogatif dari proses server-FTP untuk memohon akses
kontrol.
ukuran byte
Ada dua ukuran byte yang menarik di FTP: byte logis
ukuran file, dan ukuran transfer byte digunakan untuk
transmisi data. Ukuran Transfer byte selalu 8
bit. Ukuran Transfer byte belum tentu ukuran byte
di mana data akan disimpan dalam sistem, maupun byte logis
ukuran untuk interpretasi struktur data.
Postel & Reynolds [Halaman 3]
RFC 959 Oktober 1985
File Transfer Protocol
koneksi kontrol
Jalur komunikasi antara PENGGUNA-PI dan SERVER-PI untuk
pertukaran perintah dan balasan. Koneksi ini berikut
Telnet Protocol.
koneksi data
Sambungan duplex penuh atas data yang ditransfer, dalam
Modus yang ditentukan dan jenis. Data yang ditransfer dapat menjadi bagian dari
file, seluruh file atau beberapa file. path mungkin
antara server-DTP dan user-DTP, atau antara dua
server DTPS.
port data
Proses transfer data pasif "mendengarkan" pada port data
untuk koneksi dari proses transfer aktif untuk
membuka koneksi data.
DTP
Proses transfer data menetapkan dan mengelola data
koneksi. DTP dapat pasif atau aktif.
Akhir-of-Line
Akhir-of-line urutan mendefinisikan pemisahan pencetakan
baris. Urutannya adalah Carriage Return, diikuti oleh Line Feed.
EOF
Akhir-of-file kondisi yang mendefinisikan akhir file menjadi
ditransfer.
EOR
Akhir-of-record kondisi yang mendefinisikan akhir rekor
dipindahkan.
pemulihan kesalahan
Sebuah prosedur yang memungkinkan pengguna untuk pulih dari kesalahan tertentu
seperti kegagalan baik sistem host atau proses transfer. Di
FTP, pemulihan kesalahan mungkin melibatkan restart transfer file pada sebuah
diberikan pos pemeriksaan.
Postel & Reynolds [Halaman 4]
RFC 959 Oktober 1985
File Transfer Protocol
perintah FTP
Satu set perintah yang terdiri dari informasi kontrol yang mengalir
dari user-FTP untuk proses server-FTP.
mengajukan
Sebuah memerintahkan set data komputer (termasuk program), dari
panjang sewenang-wenang, unik diidentifikasi oleh pathname a.
mode
Modus di mana data yang akan ditransfer melalui data
koneksi. Modus yang mendefinisikan format data selama transfer
termasuk EOR dan EOF. Modus Transfer didefinisikan dalam FTP adalah
dijelaskan dalam Bagian pada Mode Transmisi.
NVT
Jaringan Virtual Terminal sebagaimana didefinisikan dalam Telnet Protocol.
NVFS
Jaringan Virtual File System. Sebuah konsep yang mendefinisikan
sistem file jaringan standar dengan perintah standar dan
konvensi pathname.
halaman
Sebuah file dapat disusun sebagai seperangkat bagian independen yang disebut
halaman. FTP mendukung pengiriman file terputus-putus sebagai
diindeks halaman independen.
pathname
Path didefinisikan sebagai string karakter yang harus
input ke sistem file oleh pengguna untuk mengidentifikasi file.
Pathname biasanya berisi nama perangkat dan / atau direktori, dan
mengajukan spesifikasi nama. FTP belum menentukan standar
konvensi pathname. Setiap pengguna harus mengikuti penamaan file
konvensi sistem file yang terlibat dalam transfer.
PI
Protokol interpreter. Pengguna dan server sisi
protokol telah peran yang berbeda diterapkan dalam user-PI dan
Server-PI.
Postel & Reynolds [Halaman 5]
RFC 959 Oktober 1985
File Transfer Protocol
merekam
Sebuah file sekuensial dapat disusun sebagai jumlah bersebelahan
bagian yang disebut catatan. struktur record yang didukung oleh FTP
tapi file tidak perlu memiliki struktur record.
balasan
Sebuah balasan adalah pengakuan (positif atau negatif) yang dikirim dari
server untuk pengguna melalui koneksi kontrol dalam menanggapi FTP
perintah. Bentuk umum dari balasan adalah kode selesai
(Termasuk kode kesalahan) diikuti dengan string teks. kode
adalah untuk digunakan oleh program dan teks biasanya ditujukan untuk
pengguna manusia.
Server-DTP
Proses transfer data, di "aktif" nya normal,
menetapkan koneksi data dengan "mendengarkan" data port.
Ini set up parameter untuk transfer dan penyimpanan, dan transfer
Data pada perintah dari PI-nya. DTP dapat ditempatkan dalam
"Pasif" negara untuk mendengarkan, daripada memulai
koneksi pada port data.
server FTP proses
Sebuah proses atau serangkaian proses yang melakukan fungsi
Transfer bekerjasama file dengan proses dan user-FTP,
mungkin, server lain. Fungsi terdiri dari protokol
interpreter (PI) dan proses transfer data (DTP).
Server-PI
Protokol ini interpreter "mendengarkan" di Pelabuhan L untuk
koneksi dari user-PI dan menetapkan kontrol
koneksi komunikasi. Ini menerima perintah FTP standar
dari user-PI, mengirimkan balasan, dan mengatur server-DTP.
mengetik
Jenis representasi data yang digunakan untuk transfer data dan
penyimpanan. Jenis menyiratkan transformasi tertentu antara waktu
penyimpanan data dan transfer data. Jenis representasi
didefinisikan dalam FTP dijelaskan dalam Bagian pada Membangun
Koneksi data.
Postel & Reynolds [Halaman 6]
RFC 959 Oktober 1985
File Transfer Protocol
pemakai
Seseorang atau suatu proses atas nama orang yang ingin mendapatkan
mengajukan layanan transfer. Pengguna manusia dapat berinteraksi secara langsung
dengan proses server-FTP, tetapi penggunaan proses user-FTP adalah
disukai karena desain protokol tertimbang terhadap
automata.
user-DTP
Proses transfer data "mendengarkan" pada port data untuk
sambungan dari proses server-FTP. Jika dua server
mentransfer data antara mereka, pengguna-DTP tidak aktif.
user-FTP proses
Satu set fungsi termasuk juru protokol, data
proses transfer dan user interface yang bersama-sama melakukan
fungsi transfer file bekerja sama dengan satu atau lebih
proses server-FTP. Antarmuka pengguna memungkinkan lokal
bahasa yang akan digunakan dalam perintah-balasan dialog dengan
pengguna.
user-PI
Protokol pengguna juru memulai koneksi kontrol
dari pelabuhan U untuk proses server-FTP, memulai FTP
perintah, dan mengatur user-DTP jika proses yang merupakan bagian dari
transfer file.
Postel & Reynolds [Halaman 7]
RFC 959 Oktober 1985
File Transfer Protocol
2.3. MODEL FTP
Dengan definisi di atas dalam pikiran, model berikut (ditampilkan di
Gambar 1) dapat digambarkan untuk layanan FTP.
-------------
| / --------- \ |
|| pengguna || --------
|| Antarmuka | <---> | pengguna |
| \ ---- ^ ---- / | --------
---------- | | |
| / ------ \ | FTP Perintah | / ---- V ---- \ |
|| Server | <----------------> | pengguna ||
|| PI || FTP Balasan || PI ||
| \ - ^ --- / | | \ ---- ^ ---- / |
| | | | | |
-------- | / - V --- \ | Data | / ---- V ---- \ | --------
| Berkas | <---> | Server | <----------------> | Pengguna | <---> | Berkas |
| Sistem | || DTP || koneksi || DTP || | Sistem |
-------- | \ ------ / | | \ --------- / | --------
---------- -------------
Server-FTP PENGGUNA-FTP
CATATAN: 1. sambungan data dapat digunakan di kedua arah.
2. sambungan data tidak perlu ada sepanjang waktu.
Gambar 1 Model untuk FTP Gunakan
Dalam model yang digambarkan pada Gambar 1, penafsir user-protokol
memulai koneksi kontrol. Koneksi kontrol berikut
protokol Telnet. Pada inisiasi pengguna, FTP standar
perintah dihasilkan oleh user-PI dan dikirim ke
proses server melalui koneksi kontrol. (Pengguna dapat
membuat sambungan kontrol langsung ke server-FTP, dari
terminal TAC misalnya, dan menghasilkan perintah FTP standar
independen, melewati proses user-FTP.) balasan Standar
dikirim dari server-PI ke user-PI alih kontrol
koneksi dalam menanggapi perintah.
Perintah FTP menentukan parameter untuk koneksi data
(Port data, modus transfer, jenis representasi, dan struktur) dan
sifat operasi sistem file (menyimpan, mengambil, menambahkan,
menghapus, dll). Pengguna-DTP atau menunjuk yang harus "mendengarkan" di
port data tertentu, dan server melakukan data
koneksi dan transfer data sesuai dengan yang ditentukan
parameter. Perlu dicatat bahwa port data tidak perlu di
Postel & Reynolds [Halaman 8]
RFC 959 Oktober 1985
File Transfer Protocol
host yang sama yang memulai perintah FTP melalui kontrol
koneksi, namun pengguna atau proses user-FTP harus memastikan
"Mendengarkan" pada port data tertentu. Seharusnya juga dicatat
bahwa koneksi data dapat digunakan untuk simultan mengirim dan
menerima.
Dalam situasi lain pengguna mungkin ingin mentransfer file antara
dua host, baik yang merupakan host lokal. pengguna set up
koneksi kontrol ke dua server dan kemudian mengatur untuk
koneksi data di antara mereka. Dengan cara ini, kontrol informasi
diteruskan ke user-PI tetapi data yang ditransfer antara
Server proses transfer data. Berikut ini adalah model ini
interaksi server-server.
------------ Kontrol kontrol
----------> | User-FTP | <-----------
| | User-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| Server-FTP | Data Connection | Server-FTP |
| "A" | <----------------------> | "B" |
-------------- Pelabuhan (A) Pelabuhan (B) --------------
Gambar 2
Protokol mensyaratkan bahwa koneksi kontrol terbuka sementara
transfer data berlangsung. Ini adalah tanggung jawab
pengguna untuk meminta penutupan koneksi kontrol saat
selesai menggunakan layanan FTP, sementara itu adalah server yang mengambil
tindakan. server dapat membatalkan transfer data jika kontrol
koneksi ditutup tanpa perintah.
Hubungan antara FTP dan Telnet:
FTP menggunakan protokol Telnet pada koneksi kontrol.
Hal ini dapat dicapai dengan dua cara: pertama, user-PI atau
Server-PI mungkin menerapkan aturan Telnet Protocol
langsung dalam prosedur mereka sendiri; atau, kedua, user-PI atau
server-PI dapat menggunakan modul Telnet yang ada di
sistem.
Kemudahan implementaion, kode berbagi, dan pemrograman modular
berdebat untuk pendekatan kedua. Efisiensi dan kemandirian
Postel & Reynolds [Page 9]
RFC 959 Oktober 1985
File Transfer Protocol
berdebat untuk pendekatan pertama. Dalam prakteknya, FTP mengandalkan sangat
sedikit dari Telnet Protocol, sehingga pendekatan pertama tidak
perlu melibatkan sejumlah besar kode.
3. FUNGSI TRANSFER DATA
File yang ditransfer hanya melalui koneksi data. Kontrol
koneksi digunakan untuk transfer perintah, yang menggambarkan
fungsi yang harus dilakukan, dan balasan perintah tersebut (lihat
Bagian atas Balasan FTP). Beberapa perintah prihatin dengan
transfer data antara host. perintah transfer data ini meliputi
perintah MODE yang menentukan bagaimana bit data yang menjadi
ditransmisikan, dan struktur dan TYPE perintah, yang digunakan untuk
menentukan cara di mana data yang akan diwakili. Itu
transmisi dan representasi pada dasarnya independen tetapi
"Stream" mode transmisi tergantung pada struktur file
atribut dan jika mode transmisi "Compressed" digunakan, sifat
dari byte filler tergantung pada jenis representasi.
3.1. PERNYATAAN DATA DAN PENYIMPANAN
Data ditransfer dari perangkat penyimpanan di tuan rumah pengiriman ke
perangkat penyimpanan di host penerima. Sering perlu untuk
melakukan transformasi tertentu pada data karena penyimpanan data
representasi dalam dua sistem yang berbeda. Sebagai contoh,
NVT-ASCII memiliki representasi penyimpanan data yang berbeda di berbagai
sistem. Desember TOPS-20-an umumnya menyimpan NVT-ASCII lima 7-bit
karakter ASCII, kiri-dibenarkan dalam kata 36-bit. IBM Mainframe ini
toko NVT-ASCII sebagai 8-bit kode EBCDIC. toko Multics NVT-ASCII
empat karakter 9-bit dalam satu kata 36-bit. Hal ini diinginkan untuk
mengkonversi karakter ke dalam standar NVT-ASCII representasi ketika
transmisi teks antara sistem yang berbeda. Pengiriman dan
menerima situs harus melakukan yang diperlukan
transformasi antara representasi standar dan mereka
representasi internal.
Sebuah masalah yang berbeda dalam representasi muncul ketika transmisi
data biner (tidak kode karakter) antara sistem host dengan
panjang kata yang berbeda. Hal ini tidak selalu jelas bagaimana pengirim
harus mengirim data, dan penerima menyimpannya. Misalnya, ketika
transmisi byte 32-bit dari 32-bit kata-panjang sistem ke
36-bit sistem kata-panjang, mungkin diinginkan (untuk alasan
efisiensi dan kegunaan) untuk menyimpan byte 32-bit
benar-benar dalam kata 36-bit dalam sistem yang terakhir. dalam setiap
kasus, pengguna harus memiliki pilihan untuk menentukan data
representasi dan transformasi fungsi. Perlu dicatat
Postel & Reynolds [Halaman 10]
RFC 959 Oktober 1985
File Transfer Protocol
yang FTP menyediakan sangat terbatas tipe data representasi.
Transformasi yang diinginkan di luar kemampuan terbatas ini harus
dilakukan oleh pengguna secara langsung.
3.1.1. JENIS DATA
representasi data ditangani dalam FTP oleh pengguna menentukan
Jenis representasi. Jenis ini dapat secara implisit (seperti dalam ASCII atau
EBCDIC) atau secara eksplisit (seperti dalam byte lokal) mendefinisikan ukuran byte untuk
interpretasi yang disebut sebagai "ukuran byte logis."
Catatan bahwa ini tidak ada hubungannya dengan ukuran byte yang digunakan untuk
pengiriman melalui sambungan data, yang disebut "Transfer
ukuran byte ", dan dua tidak harus bingung. Misalnya,
NVT-ASCII memiliki ukuran byte logis dari 8 bit. Jika jenisnya adalah
byte lokal, maka perintah TYPE memiliki kedua wajib
parameter menentukan ukuran byte logis. Transfer byte
Ukuran selalu 8 bit.
3.1.1.1. ASCII TYPE
Ini adalah jenis default dan harus diterima oleh semua FTP
implementasi. Hal ini dimaksudkan terutama untuk transfer
file teks, kecuali jika kedua host akan menemukan EBCDIC
mengetik lebih nyaman.
Pengirim mengkonversi data dari karakter internal yang
representasi dengan standar 8-bit NVT-ASCII
representasi (lihat spesifikasi Telnet). Penerima
akan mengkonversi data dari bentuk standar untuk sendiri
bentuk internal.
Sesuai dengan standar NVT, yang <CRLF> urut
harus digunakan bila perlu untuk menunjukkan akhir baris
teks. (Lihat pembahasan struktur file di akhir
Seksi pada Perwakilan Data dan Storage.)
Menggunakan standar representasi NVT-ASCII berarti data yang
harus ditafsirkan sebagai 8-bit byte.
Format parameter untuk ASCII dan EBCDIC jenis dibahas
di bawah.
Postel & Reynolds [Halaman 11]
RFC 959 Oktober 1985
File Transfer Protocol
3.1.1.2. TYPE EBCDIC
Jenis ini dimaksudkan untuk transfer efisien antara host
yang menggunakan EBCDIC untuk karakter internal mereka
perwakilan.
Untuk transmisi, data direpresentasikan sebagai 8-bit EBCDIC
karakter. Kode karakter adalah satu-satunya perbedaan
antara spesifikasi fungsional dari EBCDIC dan ASCII
jenis.
End-of-line (sebagai lawan untuk mengakhiri-of-record - lihat diskusi
struktur) mungkin akan jarang digunakan dengan jenis EBCDIC
untuk tujuan struktur yang menunjukkan, tapi di mana itu adalah
diperlukan dalam <NL> karakter harus digunakan.
3.1.1.3. IMAGE TYPE
Data tersebut dikirim sebagai bit bersebelahan yang, untuk transfer,
yang dikemas dalam transfer byte 8-bit. penerima yang
situs harus menyimpan data sebagai bit bersebelahan. Struktur
dari sistem penyimpanan mungkin memerlukan padding dari
file (atau dari setiap record, untuk file rekaman-terstruktur) untuk
beberapa batas nyaman (byte, kata atau blok). Ini
padding, yang harus semua nol, dapat terjadi hanya di akhir
file (atau pada akhir setiap record) dan harus ada
cara mengidentifikasi padding bit sehingga mereka mungkin
menanggalkan jika file yang diambil. padding
transformasi harus dipublikasikan dengan baik untuk memungkinkan pengguna untuk
memproses file di situs penyimpanan.
Jenis gambar ini dimaksudkan untuk penyimpanan yang efisien dan
pengambilan file dan untuk transfer data biner. Saya t
Disarankan bahwa jenis ini dapat diterima oleh semua FTP
implementasi.
3.1.1.4. TYPE LOKAL
Data ditransfer dalam byte logis dari ukuran
ditentukan oleh wajib kedua parameter, ukuran Byte.
Nilai ukuran Byte harus bilangan bulat desimal; ada
tidak ada nilai default. Ukuran byte logis tidak selalu
sama dengan ukuran transfer byte. Jika ada
Perbedaan dalam ukuran byte, maka byte logis harus
dikemas contiguously, mengabaikan batas Transfer byte
dan dengan padding yang diperlukan di akhir.
Postel & Reynolds [Halaman 12]
RFC 959 Oktober 1985
File Transfer Protocol
Ketika data mencapai host penerima, maka akan
diubah dengan cara tergantung pada ukuran byte logis
dan host tertentu. transformasi ini harus
dibalik (yaitu, file yang sama dapat diambil jika
parameter yang sama digunakan) dan harus dipublikasikan dengan baik oleh
pelaksana FTP.
Misalnya, pengguna mengirimkan 36-bit floating-point untuk
host dengan kata 32-bit bisa mengirim data sebagai byte lokal
dengan ukuran byte logis dari 36. host penerima akan
maka diharapkan untuk menyimpan byte logis sehingga mereka
bisa dengan mudah dimanipulasi; dalam contoh ini menempatkan
36-bit byte logis ke 64-bit kata-kata ganda harus
cukup.
Dalam contoh lain, sepasang host dengan ukuran word 36-bit
dapat mengirimkan data ke satu sama lain dalam kata-kata dengan menggunakan TYPE L 36.
Data akan dikirim dalam byte transmisi 8-bit
dikemas sehingga 9 byte transmisi dilakukan dua kata tuan.
3.1.1.5. FORMAT KONTROL
Jenis ASCII dan EBCDIC juga mengambil kedua (opsional)
parameter; ini adalah untuk menunjukkan apa jenis format vertikal
kontrol, jika ada, terkait dengan file. Pengikut
jenis representasi data didefinisikan dalam FTP:
Sebuah file karakter dapat ditransfer ke host untuk salah satu
tiga tujuan: untuk pencetakan, penyimpanan dan kemudian
pengambilan, atau untuk pengolahan. Jika file yang dikirim untuk
pencetakan, host penerima harus tahu bagaimana vertikal
kontrol Format diwakili. Dalam kasus kedua, itu harus
mungkin untuk menyimpan file di host dan kemudian mengambilnya
kemudian di bentuk yang sama persis. Akhirnya, itu harus
mungkin untuk memindahkan file dari satu host ke yang lain dan proses
file di host kedua tanpa kesulitan yang tidak semestinya. Tunggal
ASCII atau EBCDIC format tidak memenuhi semua ini
kondisi. Oleh karena itu, jenis ini memiliki parameter kedua
menentukan salah satu dari tiga format berikut:
3.1.1.5.1. PRINT NON
Ini adalah format default yang akan digunakan jika kedua
(Format) parameter dihilangkan. format non-cetak harus
diterima oleh semua implementasi FTP.
Postel & Reynolds [Halaman 13]
RFC 959 Oktober 1985
File Transfer Protocol
file perlu berisi informasi format yang vertikal. Jika
itu akan diteruskan ke proses printer, proses ini mungkin
mengasumsikan nilai standar untuk jarak dan margin.
Biasanya, format ini akan digunakan dengan file ditakdirkan
untuk pengolahan atau hanya penyimpanan.
3.1.1.5.2. KONTROL TELNET FORMAT
File ini berisi ASCII / EBCDIC Format vertikal kontrol
(Yaitu, <CR>, <LF>, <NL>, <VT>, <FF>) yang printer
Proses akan menafsirkan dengan tepat. <CRLF>, persis
urutan ini, juga menunjukkan akhir-of-line.
3.1.1.5.2. PENGANGKUTAN KONTROL (ASA)
File ini berisi ASA (FORTRAN) kontrol Format vertikal
karakter. (Lihat RFC 740 Lampiran C; dan Komunikasi
dari ACM, Vol. 7, No 10, p. 606, Oktober 1964.) Dalam
line atau catatan diformat sesuai dengan Standar ASA,
karakter pertama tidak akan dicetak. Sebaliknya,
harus digunakan untuk menentukan pergerakan vertikal dari
kertas yang harus dilakukan sebelum sisa
catatan dicetak.
ASA Standard menentukan kontrol berikut
karakter:
Karakter Spasi Vertikal
kosong Pindahkan kertas sampai satu baris
0 Pindahkan kertas sampai dua baris
1 Pindahkan kertas ke atas halaman berikutnya
+ Tidak ada gerakan, yaitu, mencetak
Jelas harus ada beberapa cara untuk proses printer untuk
membedakan akhir entitas struktural. Jika file
memiliki catatan struktur (lihat di bawah) ini tidak ada masalah;
catatan akan secara eksplisit ditandai selama transfer dan
penyimpanan. Jika berkas ini tidak memiliki struktur record, yang <CRLF>
end-of-line urutan digunakan untuk memisahkan jalur pencetakan,
tapi format efektor ini diganti oleh ASA
kontrol.
Postel & Reynolds [Halaman 14]
RFC 959 Oktober 1985
File Transfer Protocol
3.1.2. STRUKTUR DATA
Selain jenis representasi yang berbeda, FTP memungkinkan
struktur file yang akan ditentukan. Tiga struktur berkas yang
didefinisikan dalam FTP:
File-struktur, di mana tidak ada struktur internal dan
file tersebut dianggap sebagai
urutan yang kontinu byte data,
record-struktur, di mana file tersebut terdiri dari berurutan
catatan,
dan halaman-struktur, di mana file tersebut terdiri dari independen
halaman diindeks.
File-struktur adalah default yang akan diasumsikan jika struktur
Perintah belum digunakan namun kedua berkas dan struktur record
harus diterima untuk "text" file (misalnya, file dengan TYPE ASCII
atau EBCDIC) oleh semua implementasi FTP. Struktur file
akan mempengaruhi baik modus transfer file (lihat Bagian yang
pada Mode Transmisi) dan interpretasi dan penyimpanan
berkas.
"Alami" struktur file akan tergantung pada tuan rumah
menyimpan file. Sebuah file source-code biasanya akan disimpan di
Mainframe IBM dalam catatan panjang tetap tetapi pada Desember TOPS-20
sebagai aliran karakter dipartisi ke baris, misalnya
oleh <CRLF>. Jika transfer file antara yang berbeda seperti
situs ini untuk menjadi berguna, harus ada beberapa cara untuk satu situs ke situs
mengenali asumsi lain tentang file.
Dengan beberapa situs yang secara alami mengajukan berorientasi dan lain-lain
alami merekam berorientasi mungkin ada masalah jika sebuah file dengan
satu struktur dikirim ke host yang berorientasi ke yang lain. Jika sebuah
file teks yang dikirim dengan catatan-struktur ke host yang berkas
berorientasi, maka host harus menerapkan internal
transformasi ke file berdasarkan struktur record.
Jelas, transformasi ini harus berguna, tapi harus
juga dapat dibalik sehingga file yang sama dapat diambil
menggunakan struktur record.
Dalam kasus file yang dikirim dengan berkas-struktur untuk
record-berorientasi tuan rumah, terdapat pertanyaan tentang apa
Kriteria tuan rumah harus digunakan untuk membagi file ke dalam catatan
yang dapat diproses secara lokal. Jika divisi ini diperlukan,
pelaksanaan FTP harus menggunakan end-of-line urutan,
Postel & Reynolds [Halaman 15]
RFC 959 Oktober 1985
File Transfer Protocol
<CRLF> untuk ASCII, atau <NL> untuk file teks EBCDIC, sebagai
pembatas. Jika implementasi FTP mengadopsi teknik ini,
harus siap untuk membalikkan transformasi jika file tersebut
diambil dengan berkas-struktur.
3.1.2.1. FILE STRUKTUR
struktur file adalah default yang akan diasumsikan jika struktur
Perintah belum digunakan.
Dalam file-struktur tidak ada struktur internal dan
File dianggap urutan data terus menerus
bytes.
3.1.2.2. REKOR STRUKTUR
struktur catatan harus diterima untuk "text" file (yaitu,
file dengan TYPE ASCII atau EBCDIC) oleh semua implementasi FTP.
Dalam catatan-struktur file terdiri dari berurutan
catatan.
3.1.2.3. HALAMAN STRUKTUR
Untuk mengirimkan file yang terputus-putus, FTP mendefinisikan halaman
struktur. File jenis ini kadang-kadang dikenal sebagai
"File akses acak" atau bahkan sebagai "file berlubang". dalam
file ada informasi kadang-kadang lain yang terkait dengan
file secara keseluruhan (misalnya, file descriptor), atau dengan
bagian dari file (misalnya, kontrol akses halaman), atau keduanya.
Dalam FTP, bagian dari file yang disebut halaman.
Untuk menyediakan berbagai ukuran halaman dan terkait
informasi, setiap halaman dikirim dengan header halaman. Halaman
Header memiliki bidang yang didefinisikan sebagai berikut:
Header panjang
Jumlah byte logis dalam header halaman
termasuk byte ini. Panjang Header minimum adalah 4.
Indeks halaman
Logis nomor halaman dari bagian file.
Ini bukan nomor urut transmisi ini
Halaman, tetapi indeks yang digunakan untuk mengidentifikasi halaman ini dari
mengajukan.
Postel & Reynolds [Halaman 16]
RFC 959 Oktober 1985
File Transfer Protocol
Data panjang
Jumlah byte logis dalam data halaman. Itu
minimum panjang data adalah 0.
halaman Type
Jenis halaman ini. Jenis halaman berikut
didefinisikan:
0 = Akhir
Ini digunakan untuk menunjukkan akhir paged sebuah
transmisi terstruktur. Panjang Header keharusan
menjadi 4, dan panjang data harus 0.
1 = Simple Halaman
Ini adalah jenis normal untuk file paged sederhana
tanpa kontrol level halaman yang terkait
informasi. Panjang Header harus 4.
2 = Descriptor Halaman
Jenis ini digunakan untuk mengirimkan deskriptif
informasi untuk file secara keseluruhan.
3 = Akses Terkendali Halaman
Jenis ini termasuk kolom header tambahan
untuk file paged dengan kontrol akses tingkat halaman
informasi. Panjang Header harus 5.
Fields opsional
field header lanjut dapat digunakan untuk memasok per halaman
mengontrol informasi, misalnya, per akses halaman
kontrol.
Semua bidang yang satu byte logis panjang. Byte logis
Ukuran ditentukan oleh perintah TYPE. Lihat Lampiran I untuk
Rincian lebih lanjut dan kasus tertentu di struktur halaman.
Sebuah catatan dari hati-hati tentang parameter: file harus disimpan dan
diambil dengan parameter yang sama jika versi diambil adalah untuk
Postel & Reynolds [Halaman 17]
RFC 959 Oktober 1985
File Transfer Protocol
identik dengan versi awalnya dikirim. Sebaliknya,
implementasi FTP harus kembali file identik dengan aslinya
jika parameter yang digunakan untuk menyimpan dan mengambil file yang sama.
3.2. MEMBANGUN KONEKSI DATA
Mekanisme mentransfer data terdiri dari menyiapkan data
koneksi ke port yang sesuai dan memilih parameter
untuk transfer. Baik pengguna dan server-DTPS memiliki default
port data. Pengguna-proses port data default adalah sama dengan
control port koneksi (yaitu, U). Server-proses standar
port data adalah port berdekatan dengan kontrol port koneksi
(Yaitu, L-1).
Ukuran Transfer byte adalah 8-bit byte. Ukuran byte ini relevan
hanya untuk transfer sebenarnya dari data; tidak memiliki bantalan pada
representasi data dalam sistem file host.
Proses transfer data pasif (ini mungkin user-DTP atau
kedua server DTP) akan "mendengarkan" pada port data sebelum
mengirimkan perintah permintaan transfer. FTP permintaan perintah
menentukan arah transfer data. Server, setelah
menerima permintaan transfer, akan memulai koneksi data
ke pelabuhan. Ketika sambungan dibuat, data
Transfer dimulai antara DTP ini, dan server-PI mengirimkan
mengkonfirmasikan balasan ke user-PI.
Setiap pelaksanaan FTP harus mendukung penggunaan data standar
port, dan hanya PENGGUNA-PI dapat memulai perubahan ke non-default
port.
Hal ini dimungkinkan bagi pengguna untuk menentukan port data alternatif dengan
menggunakan perintah PORT. Pengguna mungkin ingin file dibuang pada TAC
printer line atau diambil dari host pihak ketiga. Di kedua
kasus, pengguna-PI set up koneksi kontrol dengan baik
Server-PI. Satu server kemudian diberitahu (oleh perintah FTP) untuk
"Mendengarkan" untuk koneksi yang lain akan memulai. Itu
user-PI mengirimkan satu server-PI perintah PORT menunjukkan data
pelabuhan yang lain. Akhirnya, keduanya dikirim sesuai
perintah transfer. Tepat urutan perintah dan balasan
dikirim antara pengguna-controller dan server didefinisikan dalam
Bagian atas FTP Balasan.
Secara umum, itu adalah tanggung jawab server untuk mempertahankan data
koneksi - untuk memulai dan untuk menutupnya. Pengecualian untuk ini
Postel & Reynolds [Halaman 18]
RFC 959 Oktober 1985
File Transfer Protocol
adalah ketika pengguna-DTP mengirimkan data dalam modus transfer yang
membutuhkan koneksi yang akan ditutup untuk menunjukkan EOF. server
HARUS menutup sambungan data dengan ketentuan sebagai berikut:
1. Server telah menyelesaikan pengiriman data dalam modus transfer
yang membutuhkan dekat dengan menunjukkan EOF.
2. Server menerima perintah ABORT dari pengguna.
3. Port spesifikasi diubah oleh perintah dari
pengguna.
4. koneksi kontrol ditutup secara hukum atau sebaliknya.
5. Sebuah kondisi irrecoverable kesalahan terjadi.
Jika tidak dekat adalah pilihan server, latihan dari mana
server harus menunjukkan kepada pengguna-proses baik 250 atau 226
balas saja.
3.3. MANAJEMEN HUBUNGAN DATA
Default Sambungan Data Port: Semua implementasi FTP harus
dukungan penggunaan port koneksi data default, dan hanya
User-PI dapat memulai penggunaan port non-default.
Negosiasi Data Port Non-Default: Pengguna-PI mungkin menentukan
non-default port data sisi pengguna dengan perintah PORT. Itu
User-PI dapat meminta sisi server untuk mengidentifikasi non-default
port data sisi server dengan perintah PASV. Sejak sambungan
didefinisikan oleh sepasang alamat, salah satu dari tindakan ini adalah
cukup untuk mendapatkan koneksi data yang berbeda, masih diperbolehkan
untuk melakukan keduanya perintah untuk menggunakan port baru pada kedua ujung data
koneksi.
Penggunaan kembali Connection Data: Bila menggunakan modus aliran data
mentransfer akhir file tersebut harus ditunjukkan dengan menutup
koneksi. Hal ini menyebabkan masalah jika beberapa file yang menjadi
ditransfer dalam sesi, karena perlu untuk TCP untuk memegang
koneksi rekor waktu keluar periode untuk menjamin terpercaya
komunikasi. Sehingga koneksi tidak dapat dibuka kembali sekaligus.
Ada dua solusi untuk masalah ini. Yang pertama adalah untuk
menegosiasikan port non-default. yang kedua adalah dengan menggunakan lain
modus transfer.
Sebuah komentar pada mode transfer. Modus transfer stream
Postel & Reynolds [Halaman 19]
RFC 959 Oktober 1985
File Transfer Protocol
inheren tidak dapat diandalkan, karena seseorang tidak dapat menentukan apakah
koneksi ditutup sebelum waktunya atau tidak. Mode transfer lain
(Block, Compressed) tidak menutup sambungan untuk menunjukkan
akhir file. Mereka memiliki cukup FTP encoding bahwa data
koneksi dapat diurai untuk menentukan akhir file.
Sehingga menggunakan mode ini salah satu dapat meninggalkan koneksi data terbuka
untuk beberapa transfer file.
3.4. CARA TRANSMISI
Pertimbangan berikutnya dalam mentransfer data adalah memilih
mode transmisi yang sesuai. Ada tiga mode: satu yang
format data dan memungkinkan untuk prosedur Restart; salah satu yang juga
kompres data untuk transfer yang efisien; dan satu yang melewati
data dengan sedikit atau tanpa pengolahan. Dalam kasus terakhir ini mode
berinteraksi dengan atribut struktur untuk menentukan jenis
pengolahan. Dalam mode kompresi, jenis representasi
menentukan byte filler.
Semua transfer data harus diselesaikan dengan end-of-file (EOF)
yang mungkin secara eksplisit dinyatakan atau tersirat oleh penutupan
koneksi data. Untuk file dengan struktur record, semua
end-of-record penanda (EOR) yang eksplisit, termasuk yang terakhir.
Untuk file ditransmisikan dalam struktur halaman "terakhir-halaman" jenis halaman ini
bekas.
CATATAN: Pada bagian ini, byte berarti "Transfer byte"
kecuali secara eksplisit dinyatakan lain.
Untuk tujuan transfer standar, tuan rumah pengiriman akan
menerjemahkan akhir internal baris atau akhir rekaman denotasi
ke dalam representasi yang ditentukan oleh modus transfer file dan
struktur, dan host penerima akan melakukan kebalikannya
terjemahan ke denotasi internal. Catatan Mainframe IBM
bidang count tidak dapat diakui di host lain, sehingga
end-of-record informasi dapat ditransfer sebagai kontrol dua byte
kode dalam mode Streaming atau sebagai sedikit ditandai di Blok atau Compressed
Modus descriptor. End-of-line dalam ASCII atau berkas EBCDIC tanpa
struktur record harus ditunjukkan dengan <CRLF> atau <NL>,
masing-masing. Sejak transformasi ini menyiratkan bekerja ekstra untuk
beberapa sistem, sistem identik mentransfer non-record terstruktur
file teks mungkin ingin menggunakan representasi biner dan streaming
modus untuk transfer.
Postel & Reynolds [Halaman 20]
RFC 959 Oktober 1985
File Transfer Protocol
Mode transmisi berikut didefinisikan dalam FTP:
3.4.1. STREAM MODE
Data ditransmisikan sebagai aliran byte. Tidak ada
pembatasan pada jenis representasi yang digunakan; struktur record
diijinkan.
Dalam catatan terstruktur EOR berkas dan EOF masing-masing akan ditunjukkan
oleh kode kontrol dua-byte. Byte pertama dari kode kontrol
akan semua orang, karakter escape. Kedua byte akan
memiliki bit orde rendah dan nol di tempat lain untuk EOR dan
kedua rendah agar sedikit selama EOF; yaitu, byte akan memiliki
nilai 1 untuk EOR dan nilai 2 untuk EOF. EOR dan EOF mungkin
ditunjukkan bersama-sama pada byte terakhir ditransmisikan dengan memutar kedua
urutan bit rendah dari (yaitu, nilai 3). Jika byte semua orang
dimaksudkan untuk dikirim sebagai data, harus diulang di
byte kedua dari kode kontrol.
Jika struktur adalah struktur file, EOF yang ditunjukkan oleh
host pengirim menutup koneksi data dan semua byte
byte data.
3.4.2. BLOK MODE
file ditransmisikan sebagai rangkaian blok data didahului dengan
satu atau lebih byte sundulan. Byte Header berisi hitungan
lapangan, dan kode deskriptor. Bidang count menunjukkan
Total panjang dari blok data dalam byte, sehingga menandai
mulai dari blok data berikutnya (tidak ada filler bit).
Kode descriptor mendefinisikan: blok terakhir di file (EOF) lalu
blok dalam catatan (EOR), penanda restart (lihat Bagian pada
Kesalahan Pemulihan dan Restart) atau suspect data (yaitu, data
dipindahkan diduga kesalahan dan tidak dapat diandalkan).
kode terakhir ini tidak dimaksudkan untuk pengendalian error dalam FTP.
Hal ini didorong oleh keinginan situs bertukar jenis tertentu
data (misalnya, gempa atau data cuaca) untuk mengirim dan menerima semua
data meskipun kesalahan lokal (seperti "pita magnetik membaca
kesalahan "), tapi untuk menunjukkan dalam transmisi yang tertentu
Bagian tersangka). struktur record yang diperbolehkan dalam ini
modus, dan jenis representasi dapat digunakan.
Header terdiri dari tiga byte. Dari 24 bit
informasi header, 16 order bit rendah akan mewakili byte
menghitung, dan 8 tinggi order bit akan mewakili deskripsi
Kode seperti yang ditunjukkan di bawah ini.
Postel & Reynolds [Halaman 21]
RFC 959 Oktober 1985
File Transfer Protocol
blok header
+ ---------------- + ---------------- + --------------- - +
| descriptor | Byte Hitungan |
| 8 bit | 16 bit |
+ ---------------- + ---------------- + --------------- - +
Kode descriptor ditunjukkan dengan bendera bit di
descriptor byte. Empat kode telah ditetapkan, di mana masing-masing
nomor kode adalah nilai desimal dari bit yang sesuai di
byte.
Arti kode
128 Akhir blok data adalah EOR
64 Akhir blok data adalah EOF
32 kesalahan Diduga di blok data
16 blok data adalah penanda me-restart
Dengan pengkodean, lebih dari satu deskripsi kondisi kode
mungkin ada untuk blok tertentu. Seperti banyak bit yang diperlukan
dapat ditandai.
Restart penanda tertanam dalam aliran data sebagai
jumlah integral byte 8-bit yang mewakili dicetak
karakter dalam bahasa yang digunakan di atas kontrol
koneksi (misalnya, standar - NVT-ASCII). <SP> (Space, di
bahasa yang sesuai) tidak boleh digunakan DALAM penanda restart.
Misalnya, untuk mengirimkan penanda enam karakter, berikut
akan dikirim:
+ -------- + -------- + -------- +
| Descrptr | count byte |
| Kode = 16 | = 6 |
+ -------- + -------- + -------- +
+ -------- + -------- + -------- +
| Marker | Marker | Marker |
| 8 bit | 8 bit | 8 bit |
+ -------- + -------- + -------- +
+ -------- + -------- + -------- +
| Marker | Marker | Marker |
| 8 bit | 8 bit | 8 bit |
+ -------- + -------- + -------- +
Postel & Reynolds [Halaman 22]
RFC 959 Oktober 1985
File Transfer Protocol
3.4.3. MODE pipih
Ada tiga jenis informasi yang akan dikirim: data biasa,
dikirim string byte; Data dikompresi, yang terdiri dari
ulangan atau pengisi; dan kontrol informasi, dikirim dalam
dua-byte urutan escape. Jika n> 0 byte (sampai 127) dari biasa
Data yang dikirim, n byte ini diawali dengan byte dengan
paling kiri bit diatur ke 0 dan paling kanan 7 bit yang berisi
jumlah n.
Byte String:
1 7 8 8
+ - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - +
| 0 | n | | d (1) | ... | d (n) |
+ - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - +
^ ^
| --- N byte --- |
data
String n Data byte d (1), ..., d (n)
Hitungan n harus positif.
Untuk kompres string n ulangan dari data byte d, yang
berikut 2 byte yang dikirim:
Byte direplikasi:
2 6 8
+ - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - +
| 1 0 | n | | d |
+ - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - +
Sebuah string dari n byte filler dapat dikompresi menjadi satu
byte, di mana filler byte bervariasi dengan representasi
mengetik. Jika jenisnya adalah ASCII atau EBCDIC pengisi byte adalah <SP>
(Space, ASCII kode 32, kode EBCDIC 64). Jika jenisnya adalah Gambar
atau byte lokal filler adalah byte nol.
Filler String:
2 6
+ - + - + - + - + - + - + - + - +
| 1 1 | n |
+ - + - + - + - + - + - + - + - +
Urutan escape adalah byte ganda, yang pertama adalah
Postel & Reynolds [Halaman 23]
RFC 959 Oktober 1985
File Transfer Protocol
escape byte (semua nol) dan kedua yang berisi
Kode deskripsi sebagaimana didefinisikan dalam mode Block. deskriptor
Kode memiliki arti yang sama seperti dalam mode Block dan berlaku untuk
berhasil string byte.
mode kompresi berguna untuk memperoleh peningkatan bandwidth pada
transmisi jaringan yang sangat besar dengan biaya CPU ekstra.
Hal ini dapat secara efektif digunakan untuk mengurangi ukuran printer
file seperti yang dihasilkan oleh host RJE.
3.5. PEMULIHAN ERROR DAN RESTART
Tidak ada ketentuan untuk mendeteksi bit hilang atau orak-arik dalam data
transfer; tingkat kontrol kesalahan ditangani oleh TCP.
Namun, prosedur restart disediakan untuk melindungi pengguna dari
kegagalan sistem bruto (termasuk kegagalan dari sebuah host, sebuah
FTP-proses, atau jaringan yang mendasarinya).
Prosedur restart didefinisikan hanya untuk blok dan dikompresi
mode transfer data. Hal ini membutuhkan pengirim data untuk menyisipkan
kode penanda khusus dalam aliran data dengan beberapa penanda
informasi. Informasi penanda hanya memiliki makna untuk
pengirim, namun harus terdiri dari karakter yang dapat dicetak di default atau
bahasa negosiasi koneksi kontrol (ASCII atau EBCDIC).
penanda bisa mewakili bit-hitungan, rekor-hitungan, atau
Informasi lain yang sistem dapat mengidentifikasi data
pos pemeriksaan. Penerima data, jika mengimplementasikan restart
prosedur, maka akan menandai posisi yang sesuai dari ini
penanda dalam sistem penerima, dan kembali informasi ini kepada
pengguna.
Dalam hal kegagalan sistem, pengguna dapat me-restart data
transfer dengan mengidentifikasi titik penanda dengan restart FTP
prosedur. Contoh berikut menggambarkan penggunaan
prosedur restart.
Pengirim data menyisipkan sebuah blok penanda yang sesuai dalam
aliran data pada titik nyaman. Host penerima menandai
sesuai data titik dalam sistem file dan menyampaikan terakhir
dikenal pengirim dan informasi penanda penerima kepada pengguna, baik
secara langsung atau melalui koneksi kontrol dalam 110 balasan (tergantung
pada siapa yang pengirim). Dalam hal kegagalan sistem, pengguna
atau proses kontroler restart server di server lalu
penanda dengan mengirimkan perintah restart dengan kode penanda server sebagai
argumen. Perintah restart ditransmisikan melalui kontrol
Postel & Reynolds [Halaman 24]
RFC 959 Oktober 1985
File Transfer Protocol
koneksi dan segera diikuti oleh perintah (seperti
RETR, Stor atau LIST) yang sedang dijalankan ketika sistem
kegagalan terjadi.
4. FUNGSI FILE TRANSFER
Saluran komunikasi dari user-PI ke server-PI adalah
didirikan sebagai koneksi TCP dari pengguna ke server standar
Pelabuhan. Protokol pengguna juru bertanggung jawab untuk mengirimkan FTP
perintah dan menafsirkan jawaban yang diterima; server-PI
menafsirkan perintah, mengirimkan balasan dan mengarahkan DTP untuk mendirikan
koneksi data dan mentransfer data. Jika pihak kedua dengan
transfer data (proses transfer pasif) adalah user-DTP, maka
diatur melalui protokol internal host user-FTP; jika
adalah server-DTP kedua, maka diatur oleh PI pada perintah dari
pengguna-PI. Balasan FTP dibahas pada bagian berikutnya. Di
deskripsi beberapa perintah dalam bagian ini, itu adalah
membantu untuk menjadi eksplisit tentang balasan mungkin.
4.1. FTP PERINTAH
4.1.1. PERINTAH ACCESS CONTROL
Perintah berikut menentukan pengidentifikasi kontrol akses
(Kode perintah ditunjukkan dalam kurung).
USER NAME (PENGGUNA)
Bidang argumen adalah string Telnet mengidentifikasi pengguna.
Identifikasi pengguna yang yang dibutuhkan oleh
server untuk akses ke sistem file-nya. Perintah ini akan
biasanya perintah pertama dikirimkan oleh pengguna setelah
koneksi kontrol dibuat (beberapa server mungkin memerlukan
ini). Informasi identifikasi tambahan dalam bentuk
password dan / atau perintah akun juga mungkin diperlukan oleh
beberapa server. Server memungkinkan perintah USER baru menjadi
masuk pada titik apapun untuk mengubah kontrol akses
dan / atau informasi akuntansi. Ini memiliki efek
pembilasan pengguna, password, dan informasi akun sudah
disediakan dan mulai urutan masuk lagi. Semua
parameter perpindahan tidak berubah dan transfer file dalam
kemajuan selesai di bawah kontrol akses tua
parameter.
Postel & Reynolds [Halaman 25]
RFC 959 Oktober 1985
File Transfer Protocol
PASSWORD (PASS)
Bidang argumen adalah string Telnet menentukan pengguna
kata sandi. Perintah ini harus segera didahului oleh
Nama pengguna perintah, dan, untuk beberapa situs, melengkapi pengguna
identifikasi untuk kontrol akses. Sejak sandi
Informasi ini cukup sensitif, diinginkan secara umum
untuk "menutupi" atau menekan typeout. Tampak bahwa
Server tidak memiliki cara yang sangat mudah untuk mencapai hal ini. ini
Oleh karena itu tanggung jawab pengguna-FTP proses untuk menyembunyikan
informasi password sensitif.
ACCOUNT (ACCT)
Bidang argumen adalah string Telnet mengidentifikasi pengguna
rekening. Perintah ini tidak selalu berhubungan dengan USER
perintah, karena beberapa situs mungkin memerlukan akun untuk login dan
orang lain hanya untuk akses tertentu, seperti menyimpan file. Di
kasus terakhir perintah mungkin tiba setiap saat.
Ada kode balasan untuk membedakan kasus ini untuk
otomatisasi: ketika informasi rekening diperlukan untuk login,
respon terhadap perintah sandi yang sukses adalah balasan kode
332. Di sisi lain, jika informasi akun TIDAK
diperlukan untuk login, jawaban untuk password sukses
Perintah adalah 230; dan jika informasi account yang diperlukan untuk
perintah yang dikeluarkan kemudian di dialog, server harus
mengembalikan 332 atau 532 balasan tergantung pada apakah itu toko
(Sambil menunggu diterimanya perintah akun) atau membuang
perintah, masing-masing.
GANTI KERJA DIREKTORI (CWD)
Perintah ini memungkinkan pengguna untuk bekerja dengan berbeda
direktori atau dataset untuk penyimpanan file atau pengambilan tanpa
mengubah login-nya atau informasi akuntansi. Transfer
parameter yang sama tidak berubah. argumen adalah
pathname menentukan direktori atau sistem lainnya tergantung
mengajukan kelompok designator.
PERUBAHAN INDUK DIREKTORI (CDUP)
Perintah ini adalah kasus khusus dari CWD, dan termasuk ke
menyederhanakan pelaksanaan program untuk mentransfer
pohon direktori antara sistem operasi memiliki berbeda
Postel & Reynolds [Halaman 26]
RFC 959 Oktober 1985
File Transfer Protocol
sintaks untuk penamaan direktori induk. Kode balasan
harus identik dengan kode balasan dari CWD. Lihat
Lampiran II untuk rincian lebih lanjut.
STRUKTUR MOUNT (SMNT)
Perintah ini memungkinkan pengguna untuk me-mount file yang berbeda
sistem struktur data tanpa mengubah login-nya atau
informasi akuntan. Transfer parameter-sama
tidak berubah. Argumen ini pathname menentukan
direktori atau sistem lainnya tergantung group file designator.
Reinitialize (Rein)
Perintah ini berakhir PENGGUNA sebuah, pembilasan semua I / O dan akun
informasi, kecuali untuk memungkinkan transfer dalam proses untuk menjadi
lengkap. Semua parameter-reset ke pengaturan default
dan koneksi kontrol dibiarkan terbuka. Ini identik
dengan keadaan di mana pengguna menemukan dirinya segera setelah
koneksi kontrol dibuka. Perintah USER mungkin
diharapkan untuk mengikuti.
LOGOUT (QUIT)
Perintah ini berakhir USER dan jika transfer file tidak
berlangsung, server menutup koneksi kontrol. Jika
transfer file sedang berlangsung, koneksi akan tetap
terbuka untuk respon hasil dan server maka akan menutupnya.
Jika pengguna-proses mentransfer file untuk beberapa pengguna
tetapi tidak ingin menutup dan kemudian buka kembali koneksi untuk
masing-masing, maka perintah Rein harus digunakan sebagai pengganti QUIT.
Tak terduga dekat pada koneksi kontrol akan menyebabkan
server untuk mengambil tindakan efektif batalkan (ABOR) dan
logout (QUIT).
4.1.2. PERINTAH TRANSFER PARAMETER
Semua parameter transfer data memiliki nilai default, dan
perintah menentukan parameter transfer data yang diperlukan hanya
jika default nilai parameter yang harus diubah. Standar
Nilai adalah nilai yang ditentukan terakhir, atau jika tidak ada nilai telah
ditentukan, nilai default standar seperti yang dinyatakan di sini. Ini
menyiratkan bahwa server harus "ingat" default berlaku
nilai-nilai. Perintah mungkin dalam urutan apapun kecuali bahwa mereka harus
mendahului permintaan layanan FTP. Perintah berikut
menentukan parameter transfer data:
Postel & Reynolds [Halaman 27]
RFC 959 Oktober 1985
File Transfer Protocol
DATA PORT (PORT)
Argumennya adalah spesifikasi HOST-PORT untuk data port
untuk digunakan dalam koneksi data. Ada default untuk kedua
pengguna dan server port data, dan di bawah yang normal
keadaan perintah ini dan balasan yang tidak diperlukan. Jika
Perintah ini digunakan, argumen adalah gabungan dari
32-bit alamat host internet dan 16-bit alamat port TCP.
Informasi alamat ini dipecah menjadi bidang 8-bit dan
nilai masing-masing bidang ditularkan sebagai angka desimal (di
string karakter representasi). Bidang dipisahkan
dengan koma. Perintah pelabuhan akan menjadi:
PORT h1, h2, h3, h4, p1, p2
mana h1 adalah urutan tinggi 8 bit dari host internet
alamat.
PASIF (PASV)
Perintah ini meminta server-DTP untuk "mendengarkan" data yang
pelabuhan (yang tidak port data default) dan menunggu untuk
koneksi daripada memulai satu setelah menerima
mentransfer perintah. Respon terhadap perintah ini meliputi
tuan rumah dan alamat port server ini mendengarkan pada.
PERNYATAAN TYPE (TYPE)
Argumen menentukan jenis representasi seperti yang dijelaskan
di Bagian pada Representasi Data dan Storage. Beberapa
jenis mengambil parameter kedua. Parameter pertama adalah
dilambangkan dengan karakter Telnet tunggal, seperti yang kedua
Format parameter untuk ASCII dan EBCDIC; parameter kedua
untuk byte lokal adalah bilangan bulat desimal untuk menunjukkan Bytesize.
Parameter dipisahkan oleh <SP> (Space, kode ASCII
32).
Kode berikut ditugaskan untuk jenis:
\ /
A - ASCII | | N - Non-print
| -> <- | T - Telnet Format efektor
E - EBCDIC | | C - Carriage Control (ASA)
/ \
I - Gambar
L <ukuran byte> - ukuran byte Byte lokal
Postel & Reynolds [Halaman 28]
RFC 959 Oktober 1985
File Transfer Protocol
Jenis representasi default adalah ASCII Non-print. Jika
Format parameter berubah, dan kemudian hanya yang pertama
Argumen berubah, Format kemudian kembali ke Non-print
default.
FILE STRUKTUR (stru)
Argumennya adalah satu Telnet kode karakter menspesifikasikan
struktur file dijelaskan dalam Bagian pada Data
Representasi dan penyimpanan.
Kode berikut ditugaskan untuk struktur:
F - File (ada struktur record)
R - Rekam struktur
P - struktur Halaman
Struktur default adalah file.
TRANSFER MODE (MODE)
Argumennya adalah satu Telnet kode karakter menspesifikasikan
mode transfer data yang dijelaskan dalam Bagian pada
Mode transmisi.
Kode berikut ditugaskan untuk modus transfer:
S - Streaming
B - Block
C - Compressed
Modus transfer default adalah Stream.
4.1.3. PERINTAH LAYANAN FTP
Perintah layanan FTP menentukan transfer file atau file
fungsi sistem yang diminta oleh pengguna. Argumen dari FTP
Perintah layanan biasanya akan pathname a. Sintaks
nama path harus sesuai dengan konvensi server situs (dengan
default standar yang berlaku), dan konvensi bahasa
koneksi kontrol. penanganan default yang disarankan adalah untuk
menggunakan yang terakhir ditentukan perangkat, direktori atau nama file, atau
bawaan standar yang ditetapkan untuk pengguna lokal. Perintah mungkin
dalam urutan apapun kecuali bahwa "mengubah nama dari" perintah harus
diikuti dengan "mengubah nama untuk" komando dan perintah restart harus
diikuti oleh perintah layanan terganggu (misal, Stor atau
RETR). Data, saat ditransfer dalam menanggapi layanan FTP
Postel & Reynolds [Halaman 29]
RFC 959 Oktober 1985
File Transfer Protocol
perintah, harus selalu dikirim melalui koneksi data, kecuali
balasan informatif tertentu. Perintah berikut
menentukan permintaan layanan FTP:
AMBIL (RETR)
Perintah ini menyebabkan server-DTP untuk mentransfer salinan
File, ditentukan dalam pathname, ke server-atau user-DTP
di ujung lain dari koneksi data. status dan
isi dari file di server situs akan terpengaruh.
STORE (STOR)
Perintah ini menyebabkan server-DTP untuk menerima data
ditransfer melalui koneksi data dan untuk menyimpan data sebagai
file di server situs. Jika file yang ditentukan dalam
pathname ada di server situs, maka isinya akan
digantikan oleh data yang ditransfer. Sebuah file baru
dibuat di server situs jika file yang ditentukan dalam
pathname tidak sudah ada.
STORE UNIK (Stou)
Perintah ini berperilaku seperti Stor kecuali bahwa resultan
file yang akan dibuat di direktori saat ini di bawah nama
unik ke direktori tersebut. 250 transfer Dimulai respon
harus menyertakan nama dihasilkan.
APPEND (dengan membuat) (APPE)
Perintah ini menyebabkan server-DTP untuk menerima data
ditransfer melalui koneksi data dan untuk menyimpan data dalam
file di server situs. Jika file yang ditentukan dalam
pathname ada di server situs, maka data akan
ditambahkan ke file itu; jika file yang ditentukan dalam
pathname harus dibuat pada server situs.
ALOKASI (ALLO)
Perintah ini mungkin diperlukan oleh beberapa server untuk memesan
penyimpanan yang cukup untuk menampung file baru untuk menjadi
ditransfer. Argumen harus integer desimal
mewakili jumlah byte (menggunakan byte logis
ukuran) penyimpanan yang akan disediakan untuk file. untuk file
dikirim dengan catatan atau struktur halaman catatan maksimum atau halaman
Ukuran (dalam bytes logis) mungkin juga diperlukan; ini adalah
ditunjukkan dengan integer desimal dalam bidang argumen kedua
Postel & Reynolds [Halaman 30]
RFC 959 Oktober 1985
File Transfer Protocol
perintah. Argumen kedua ini opsional, tapi ketika
hadir harus dipisahkan dari yang pertama oleh tiga
karakter Telnet <SP> R <SP>. Perintah ini akan
diikuti oleh toko atau perintah append. The ALLO perintah
harus diperlakukan sebagai NOOP (tidak ada operasi) oleh orang-orang server
yang tidak mengharuskan ukuran maksimum file menjadi
menyatakan terlebih dahulu, dan server tersebut tertarik hanya
catatan atau halaman maksimum ukuran harus menerima nilai boneka
dalam argumen pertama dan mengabaikannya.
RESTART (REST)
Bidang Argumen merupakan penanda Server di mana
transfer file adalah untuk restart. Perintah ini tidak
transfer file penyebab tapi melompati file yang ditentukan
Data pos pemeriksaan. Perintah ini akan segera diikuti
dengan FTP perintah layanan yang sesuai yang akan menyebabkan
transfer file untuk melanjutkan.
RENAME DARI (RNFR)
Perintah ini menentukan path lama file yang
untuk diganti namanya. Perintah ini harus segera diikuti dengan
sebuah "mengubah nama untuk" perintah menentukan letak file baru.
RENAME TO (RNTO)
Perintah ini menentukan path baru file
ditentukan dalam segera sebelum "mengubah nama dari"
perintah. Bersama dua perintah menyebabkan file menjadi
berganti nama.
ABORT (ABOR)
Perintah ini memberitahu server untuk membatalkan FTP sebelumnya
Layanan perintah dan transfer terkait data. Itu
batalkan perintah mungkin membutuhkan "tindakan khusus", seperti yang dibahas di
Bagian pada FTP Perintah, untuk memaksa pengakuan oleh
Server. Tidak ada tindakan yang harus diambil jika perintah sebelumnya
telah selesai (termasuk transfer data). Kontrol
koneksi tidak ditutup oleh server, namun data tersebut
koneksi harus ditutup.
Ada dua kasus untuk server setelah menerima ini
perintah: (1) perintah layanan FTP sudah selesai,
atau (2) FTP perintah layanan ini masih dalam proses.
Postel & Reynolds [Halaman 31]
RFC 959 Oktober 1985
File Transfer Protocol
Dalam kasus pertama, server menutup sambungan data
(Jika terbuka) dan merespon dengan 226 balasan, yang menunjukkan
bahwa perintah batalkan berhasil diproses.
Dalam kasus kedua, server dibatalkan layanan FTP di
kemajuan dan menutup koneksi data, mengembalikan 426
membalas menunjukkan bahwa permintaan layanan dihentikan
abnormal. Server kemudian mengirimkan 226 balasan,
menunjukkan bahwa perintah batalkan itu berhasil
diproses.
DELETE (DELE)
Perintah ini menyebabkan file yang ditentukan dalam pathname untuk menjadi
dihapus di server situs. Jika tingkat perlindungan ekstra
yang diinginkan (seperti query, "Apakah Anda benar-benar ingin
menghapus? "), harus disediakan oleh proses user-FTP.
HAPUS DIREKTORI (RMD)
Perintah ini menyebabkan direktori tertentu di pathname
dihapus sebagai sebuah direktori (jika pathname adalah mutlak)
atau sebagai subdirektori dari direktori kerja saat ini (jika
pathname relatif). Lihat Lampiran II.
MEMBUAT DIREKTORI (MKD)
Perintah ini menyebabkan direktori tertentu di pathname
yang akan dibuat sebagai sebuah direktori (jika pathname adalah mutlak)
atau sebagai subdirektori dari direktori kerja saat ini (jika
pathname relatif). Lihat Lampiran II.
PRINT KERJA DIREKTORI (PWD)
Perintah ini menyebabkan nama kerja saat ini
direktori untuk dikembalikan dalam balasan. Lihat Lampiran II.
DAFTAR (LIST)
Perintah ini menyebabkan daftar yang akan dikirim dari server ke
pasif DTP. Jika pathname menentukan direktori atau lainnya
kelompok file, server harus mentransfer daftar file
di direktori yang ditentukan. Jika pathname menetapkan
mengajukan maka server harus mengirimkan informasi saat ini pada
mengajukan. Argumen nol menyiratkan pengguna kerja saat ini atau
direktori default. Transfer data melalui data yang
koneksi dalam tipe ASCII atau jenis EBCDIC. (Pengguna harus
Postel & Reynolds [Halaman 32]
RFC 959 Oktober 1985
File Transfer Protocol
memastikan bahwa TYPE adalah tepat ASCII atau EBCDIC).
Karena informasi pada file dapat bervariasi dari sistem
sistem, informasi ini mungkin sulit untuk digunakan secara otomatis
dalam sebuah program, tapi mungkin cukup berguna untuk pengguna manusia.
DAFTAR NAMA (NLST)
Perintah ini menyebabkan daftar direktori yang akan dikirim dari
server untuk pengguna situs. pathname harus menentukan
direktori atau sistem yang kelompok deskriptor file lainnya; Sebuah
Argumen nol menyiratkan direktori saat ini. server
akan kembali aliran nama file dan tidak ada lainnya
informasi. Data akan ditransfer dalam ASCII atau
Jenis EBCDIC melalui koneksi data path valid
string dipisahkan oleh <CRLF> atau <NL>. (Lagi-lagi pengguna harus
memastikan bahwa TYPE yang benar.) Perintah ini dimaksudkan
untuk kembali informasi yang dapat digunakan oleh program untuk
lanjut memproses file secara otomatis. Sebagai contoh, di
pelaksanaan fungsi "beberapa get".
PARAMETER SITE (SITE)
Perintah ini digunakan oleh server untuk memberikan layanan
khusus untuk sistemnya yang penting untuk transfer file
tapi tidak cukup universal dimasukkan sebagai perintah dalam
protokol. Sifat layanan ini dan
spesifikasi sintaks mereka dapat dinyatakan dalam balasan untuk
perintah BANTUAN SITE.
SISTEM (SYST)
Perintah ini digunakan untuk mengetahui jenis operasi
sistem pada server. Jawabannya harus memiliki sebagai yang pertama
kata salah satu nama sistem yang tercantum dalam versi saat ini
dokumen Bilangan Ditugaskan [4].
STATUS (STAT)
Perintah ini akan menimbulkan respon status dikirim melalui
koneksi kontrol dalam bentuk balasan. Perintah
dapat dikirimkan selama transfer file (bersama dengan IP Telnet
dan sinyal Synch - lihat Bagian dari FTP Perintah) di mana
kasus server akan merespon dengan status
Operasi berlangsung, atau mungkin dikirim antara berkas
transfer. Dalam kasus terakhir, perintah mungkin memiliki
bidang argumen. Jika argumen adalah pathname, perintah tersebut
analog dengan perintah "daftar" kecuali data yang akan
Postel & Reynolds [Halaman 33]
RFC 959 Oktober 1985
File Transfer Protocol
ditransfer melalui koneksi kontrol. Jika parsial
pathname diberikan, server dapat merespon dengan daftar
nama file atau atribut yang berhubungan dengan spesifikasi yang.
Jika tidak ada argumen yang diberikan, server harus kembali umum
informasi status tentang proses server FTP. Ini
harus mencakup nilai-nilai saat ini dari semua parameter perpindahan dan
status koneksi.
TOLONG TOLONG)
Perintah ini akan menyebabkan server untuk mengirim bermanfaat
informasi mengenai status pelaksanaannya selama
koneksi kontrol untuk pengguna. perintah dapat mengambil
Argumen (misal, setiap nama perintah) dan kembali lebih spesifik
informasi sebagai respon. Jawabannya adalah tipe 211 atau 214.
Disarankan bahwa BANTUAN diizinkan sebelum memasuki PENGGUNA a
perintah. server dapat menggunakan jawaban ini untuk menentukan
parameter situs-dependent, misalnya, dalam menanggapi MEMBANTU SITE.
NOOP (NOOP)
Perintah ini tidak mempengaruhi parameter atau sebelumnya
perintah yang dimasukkan. Ini menentukan ada tindakan selain itu
Server mengirim balasan OK.
File Transfer Protocol mengikuti spesifikasi Telnet yang
protokol untuk semua komunikasi melalui koneksi kontrol. Sejak
bahasa yang digunakan untuk komunikasi Telnet dapat sebuah dinegosiasikan
pilihan, semua referensi dalam dua bagian berikutnya akan ke
"Bahasa Telnet" dan sesuai "Telnet kode end-of-line".
Saat ini, satu dapat mengambil ini berarti NVT-ASCII dan <CRLF>. Tidak ada yang lain
Spesifikasi dari protokol Telnet akan dikutip.
perintah FTP yang "Telnet string" diberhentikan oleh "akhir Telnet dari
baris kode ". Kode perintah sendiri karakter abjad
diakhiri oleh karakter <SP> (Space) jika parameter mengikuti dan
Telnet-EOL sebaliknya. Kode komando dan semantik
perintah yang diuraikan dalam bagian ini; sintaks rinci
perintah yang ditentukan dalam Bagian pada Perintah, urutan balasan
dibahas dalam Bagian pada Sequencing dari Perintah dan Tanggapan,
dan skenario yang menggambarkan penggunaan perintah disediakan dalam
Bagian dari Skenario FTP khas.
perintah FTP dapat dipartisi seperti yang menentukan akses-kontrol
pengidentifikasi, parameter transfer data, atau permintaan layanan FTP.
perintah tertentu (seperti ABOR, STAT, QUIT) dapat dikirim melalui
mengontrol koneksi saat transfer data berlangsung. Beberapa
Postel & Reynolds [Halaman 34]
RFC 959 Oktober 1985
File Transfer Protocol
server mungkin tidak dapat memantau kontrol dan sambungan data
secara bersamaan, dalam hal ini beberapa tindakan khusus akan diperlukan
untuk mendapatkan perhatian server. Format memerintahkan berikut ini
tentatif direkomendasikan:
1. Sistem Pengguna memasukkan Telnet "Proses Interrupt" (IP) sinyal
dalam aliran Telnet.
2. Sistem Pengguna mengirimkan Telnet "Synch" sinyal.
3. Sistem Pengguna memasukkan perintah (misalnya, ABOR) di Telnet yang
aliran.
4. Server PI, setelah menerima "IP", scan aliran Telnet untuk
PERSIS ONE FTP perintah.
(Untuk server lain ini mungkin tidak diperlukan tetapi tindakan yang tercantum
di atas seharusnya tidak berpengaruh tidak biasa.)
4.2. balasan FTP
Balasan ke File perintah Protokol Transfer dirancang untuk memastikan
sinkronisasi permintaan dan tindakan dalam proses file
mentransfer, dan untuk menjamin bahwa proses pengguna selalu tahu
keadaan Server. Setiap perintah harus menghasilkan setidaknya satu
menjawab, walaupun mungkin ada lebih dari satu; dalam kasus terakhir,
yang beberapa balasan harus mudah dibedakan. Sebagai tambahan,
beberapa perintah terjadi pada kelompok berurutan, seperti USER, PASS di dan
ACCT, atau RNFR dan RNTO. Balasan menunjukkan keberadaan suatu
keadaan antara jika semua perintah sebelumnya telah berhasil.
Kegagalan pada setiap titik dalam urutan memerlukan pengulangan
dari keseluruhan urutan dari awal.
Rincian perintah-balasan urutan yang dibuat eksplisit dalam
seperangkat negara diagram di bawah ini.
Balasan FTP terdiri dari nomor tiga digit (dikirim sebagai
tiga karakter alfanumerik) diikuti oleh beberapa teks. Nomor
dimaksudkan untuk digunakan oleh automata untuk menentukan apa yang negara untuk masuk
berikutnya; teks ditujukan untuk pengguna manusia. Hal ini dimaksudkan
bahwa tiga digit berisi informasi dikodekan cukup bahwa
user-proses (User-PI) tidak akan perlu memeriksa teks dan
mungkin baik membuangnya atau menyebarkannya kepada pengguna, yang sesuai.
Secara khusus, teks mungkin server tergantung, jadi ada
mungkin bervariasi teks untuk setiap kode balasan.
Sebuah balasan didefinisikan mengandung kode 3 digit, diikuti oleh Space
Postel & Reynolds [Halaman 35]
RFC 959 Oktober 1985
File Transfer Protocol
<SP>, diikuti oleh satu baris teks (di mana beberapa panjang garis maksimum
telah ditentukan), dan diberhentikan oleh Telnet akhir-of-line
kode. Akan ada kasus Namun, di mana teks lebih panjang dari
satu baris. Dalam kasus ini teks lengkap harus diberi tanda kurung
sehingga User-proses yang tahu jika dapat berhenti membaca balasan (mis
berhenti memproses masukan dari koneksi kontrol) dan pergi melakukan lain
sesuatu. Ini membutuhkan format khusus pada baris pertama yang
menunjukkan bahwa lebih dari satu baris akan datang, dan satu lagi di
baris terakhir untuk menunjuk sebagai yang terakhir. Setidaknya salah satu dari ini harus
mengandung sesuai kode balasan untuk menunjukkan keadaan
transaksi. Untuk memenuhi semua faksi, diputuskan bahwa kedua
kode baris pertama dan terakhir harus sama.
Jadi format untuk multi-line menjawab adalah bahwa baris pertama
akan mulai dengan kode balasan yang tepat diperlukan, diikuti
segera oleh tanda hubung, "-" (juga dikenal sebagai Minus), diikuti oleh
teks. Baris terakhir akan dimulai dengan kode yang sama, diikuti
segera oleh Space <SP>, opsional beberapa teks, dan Telnet yang
end-of-line kode.
Sebagai contoh:
garis 123-Pertama
Baris kedua
234 Sebuah garis dimulai dengan nomor
123 Baris terakhir
Pengguna-proses maka hanya perlu mencari kedua
terjadinya kode jawaban yang sama, diikuti oleh <SP> (Space), di
awal garis, dan mengabaikan semua lini perantara. Jika
garis perantara dimulai dengan angka 3 digit, Server
harus pad depan untuk menghindari kebingungan.
Skema ini memungkinkan rutinitas standar sistem yang akan digunakan untuk
membalas informasi (seperti untuk balasan STAT), dengan
"Buatan" pertama dan terakhir garis tertempel di. Dalam kasus yang jarang terjadi
di mana rutinitas ini mampu menghasilkan tiga angka dan
Ruang pada awal setiap baris, setiap awal
baris teks harus diimbangi dengan beberapa teks yang netral, seperti Space.
Skema ini mengasumsikan bahwa multi-line balasan mungkin tidak bersarang.
Tiga digit jawabannya masing-masing memiliki makna khusus.
Hal ini dimaksudkan untuk memungkinkan berbagai sangat sederhana untuk sangat
tanggapan canggih dengan user-proses. Digit pertama
menunjukkan apakah respon yang baik, buruk atau tidak lengkap.
(Mengacu pada diagram negara), pengguna-proses canggih
akan dapat menentukan tindakan berikutnya (melanjutkan seperti yang direncanakan,
Postel & Reynolds [Halaman 36]
RFC 959 Oktober 1985
File Transfer Protocol
Redo, menghemat, dll) hanya dengan memeriksa digit pertama ini. SEBUAH
user-proses yang ingin tahu kira-kira apa jenis kesalahan
terjadi (mis sistem file error, perintah kesalahan sintaks) mungkin
memeriksa digit kedua, pemesanan digit ketiga untuk yang terbaik
gradasi informasi (misalnya, perintah RNTO tanpa sebelumnya
RNFR).
Ada lima nilai untuk digit pertama kode jawaban:
1yz Positif Awal membalas
Tindakan yang diminta sedang dimulai; berharap lain
membalas sebelum melanjutkan dengan perintah baru. (Itu
user-proses pengiriman perintah lain sebelum
selesai balasan akan melanggar protokol; tapi
proses server-FTP harus antrian perintah apapun yang
tiba sementara perintah sebelumnya sedang berlangsung.) ini
jenis yg bisa digunakan untuk menunjukkan bahwa perintah
diterima dan user-proses sekarang mungkin memperhatikan
untuk koneksi data, untuk implementasi di mana
pemantauan simultan sulit. Server-FTP
Proses dapat mengirimkan paling banyak, satu 1yz membalas per perintah.
2yz Positif Penyelesaian membalas
Tindakan yang diminta telah berhasil diselesaikan. SEBUAH
permintaan baru dapat dimulai.
3yz Positif Menengah balasan
Perintah telah diterima, namun tindakan yang diminta
sedang diadakan di penundaan, sambil menunggu diterimanya lanjut
informasi. pengguna harus mengirimkan perintah lain
menentukan informasi ini. Jawaban ini digunakan dalam
urutan perintah kelompok.
4yz Transient Negatif balasan Penyelesaian
Perintah itu tidak diterima dan tindakan yang diminta melakukan
tidak terjadi, tetapi kondisi kesalahan sementara dan
tindakan mungkin akan diminta lagi. Pengguna harus
kembali ke awal urutan perintah, jika ada.
Sulit untuk menetapkan arti untuk "sementara",
terutama ketika dua situs yang berbeda (Server-dan
User-proses) harus setuju pada interpretasi.
Setiap balasan dalam kategori 4yz mungkin memiliki sedikit
berbeda nilai waktu, tetapi tujuannya adalah bahwa
Postel & Reynolds [Halaman 37]
RFC 959 Oktober 1985
File Transfer Protocol
user-proses dianjurkan untuk mencoba lagi. Aturan praktis
dalam menentukan apakah balasan cocok dengan 4yz atau 5yz yang
(Permanent Negative) kategori adalah bahwa balasan 4yz jika
perintah dapat diulang tanpa perubahan
bentuk perintah atau sifat dari Pengguna atau Server
(Misalnya, perintah dieja sama dengan yang sama
argumen yang digunakan; pengguna tidak mengubah akses file-nya
atau nama pengguna; server tidak memasang baru
pelaksanaan.)
5yz permanen balasan Penyelesaian Negatif
Perintah itu tidak diterima dan tindakan yang diminta melakukan
tidak terjadi. Pengguna-proses berkecil dari
mengulangi permintaan yang tepat (dalam urutan yang sama). Bahkan
beberapa "permanen" kondisi kesalahan dapat diperbaiki, sehingga
pengguna manusia mungkin ingin mengarahkan User-proses untuk
memulai kembali urutan perintah dengan aksi langsung pada beberapa
titik di masa depan (misalnya, setelah ejaan telah
diubah, atau pengguna telah diubah statusnya direktori nya.)
Pengelompokan fungsi berikut dikodekan dalam kedua
digit:
x0z Syntax - balasan ini mengacu pada sintaks kesalahan,
perintah sintaksis benar yang tidak cocok apapun
kategori fungsional, diimplementasikan atau berlebihan
perintah.
x1z Informasi - Ini adalah balasan untuk permintaan
informasi, seperti status atau bantuan.
x2z Koneksi - Tanggapan mengacu kontrol dan
koneksi data.
x3z Otentikasi dan akuntansi - Balasan untuk login
Proses dan prosedur akuntansi.
x4z Tidak disebutkan belum.
Sistem x5z File - balasan ini menunjukkan status
sistem file server yang vis-a-vis transfer yang diminta atau
Tindakan sistem file lain.
Angka ketiga memberikan gradasi halus makna di setiap
kategori fungsi, yang ditentukan oleh digit kedua. Itu
daftar balasan di bawah ini akan menggambarkan hal ini. Perhatikan bahwa teks
Postel & Reynolds [Halaman 38]
RFC 959 Oktober 1985
File Transfer Protocol
terkait dengan setiap balasan dianjurkan, bukan
wajib, dan bahkan dapat berubah sesuai dengan perintah dengan
yang dikaitkan. Kode balasan, di sisi lain,
harus ketat mengikuti spesifikasi pada bagian terakhir;
yaitu, implementasi Server tidak harus menciptakan kode baru untuk
situasi yang hanya sedikit berbeda dari yang
dijelaskan di sini, melainkan harus beradaptasi kode sudah ditetapkan.
Perintah seperti TYPE atau Allo yang sukses eksekusi
tidak menawarkan user-proses informasi baru akan
menyebabkan 200 balasan untuk dikembalikan. Jika perintah ini tidak
dilaksanakan oleh proses Server-FTP tertentu karena
tidak memiliki relevansi dengan sistem komputer, misalnya ALLO
di situs TOPS20, balasan Positif Penyelesaian masih
diinginkan sehingga User-proses yang sederhana tahu itu dapat melanjutkan
dengan tindakannya. Sebuah 202 balasan digunakan dalam kasus ini
dengan, misalnya, jawaban teks: "Tidak ada alokasi penyimpanan
diperlukan. "Jika, di sisi lain, perintah meminta
Tindakan-non-situs tertentu dan diimplementasikan, respon
adalah 502. Sebuah penyempurnaan dari yang adalah 504 balasan untuk perintah
yang diimplementasikan, tetapi yang meminta sebuah unimplemented
parameter.
4.2.1 Balas Kode oleh Fungsi Grup
200 Command oke.
500 Kesalahan sintaks, perintah tidak dikenal.
Ini mungkin termasuk kesalahan seperti baris perintah terlalu lama.
501 Kesalahan sintaks dalam parameter atau argumen.
202 Perintah tidak dilaksanakan, berlebihan di situs ini.
502 Perintah tidak diimplementasikan.
503 urutan Bad perintah.
504 Perintah tidak diimplementasikan untuk parameter itu.
Postel & Reynolds [Halaman 39]
RFC 959 Oktober 1985
File Transfer Protocol
110 Restart balasan penanda.
Dalam hal ini, teks yang tepat dan tidak diserahkan kepada
implementasi tertentu; itu harus membaca:
MARK yyyy = mmmm
Dimana yyyy adalah User-proses aliran data marker, dan mmmm
server setara penanda (perhatikan spasi antara spidol
dan "=").
Status 211 System, atau sistem bantuan balasan.
212 Status Directory.
213 Status Berkas.
214 Bantuan pesan.
Tentang cara menggunakan server atau arti tertentu
perintah non-standar. Jawaban ini hanya berguna untuk
pengguna manusia.
215 Jenis sistem NAME.
Di mana NAME adalah nama sistem resmi dari daftar di
Dokumen Nomor ditugaskan.
120 Layanan siap dalam beberapa menit nnn.
220 Layanan siap pengguna baru.
221 Layanan menutup sambungan kontrol.
Log out jika sesuai.
421 Layanan tidak tersedia, menutup koneksi kontrol.
Ini mungkin balasan untuk perintah apapun jika layanan tahu itu
harus ditutup.
125 Koneksi data sudah terbuka; Transfer awal.
225 koneksi data terbuka; ada transfer berlangsung.
425 Tidak dapat membuka koneksi data.
226 Menutup koneksi data.
Meminta tindakan berkas berhasil (misalnya, berkas
mentransfer atau berkas batalkan).
426 Koneksi ditutup; Transfer dibatalkan.
227 Memasuki Mode pasif (h1, h2, h3, h4, p1, p2).
230 Pengguna login, lanjutkan.
530 Tidak login.
331 Nama pengguna oke, membutuhkan password.
332 Perlu akun untuk login.
532 Perlu akun untuk menyimpan file.
Postel & Reynolds [Halaman 40]
RFC 959 Oktober 1985
File Transfer Protocol
150 Status Berkas-baik saja; akan membuka koneksi data.
250 Diminta tindakan berkas-baik saja, selesai.
257 "pathname" diciptakan.
350 Diminta tindakan berkas menunggu informasi lebih lanjut.
450 Diminta tindakan berkas tidak diambil.
File tidak tersedia (misalnya, mengajukan sibuk).
550 tindakan Diminta tidak diambil.
File tidak tersedia (misalnya, file tidak ditemukan, tidak ada akses).
451 tindakan Diminta dibatalkan. Kesalahan lokal dalam pengolahan.
551 tindakan Diminta dibatalkan. Jenis halaman diketahui.
452 tindakan Diminta tidak diambil.
ruang penyimpanan tidak cukup dalam sistem.
552 Diminta tindakan berkas dibatalkan.
alokasi penyimpanan melebihi (untuk direktori saat ini atau
dataset).
553 tindakan Diminta tidak diambil.
File name tidak diperbolehkan.
4.2.2 Numeric Orde Daftar Kode Balas
110 Restart balasan penanda.
Dalam hal ini, teks yang tepat dan tidak diserahkan kepada
implementasi tertentu; itu harus membaca:
MARK yyyy = mmmm
Dimana yyyy adalah User-proses aliran data marker, dan mmmm
server setara penanda (perhatikan spasi antara spidol
dan "=").
120 Layanan siap dalam beberapa menit nnn.
125 Koneksi data sudah terbuka; Transfer awal.
150 Status Berkas-baik saja; akan membuka koneksi data.
Postel & Reynolds [Halaman 41]
RFC 959 Oktober 1985
File Transfer Protocol
200 Command oke.
202 Perintah tidak dilaksanakan, berlebihan di situs ini.
Status 211 System, atau sistem bantuan balasan.
212 Status Directory.
213 Status Berkas.
214 Bantuan pesan.
Tentang cara menggunakan server atau arti tertentu
perintah non-standar. Jawaban ini hanya berguna untuk
pengguna manusia.
215 Jenis sistem NAME.
Di mana NAME adalah nama sistem resmi dari daftar di
Dokumen Nomor ditugaskan.
220 Layanan siap pengguna baru.
221 Layanan menutup sambungan kontrol.
Log out jika sesuai.
225 koneksi data terbuka; ada transfer berlangsung.
226 Menutup koneksi data.
Meminta tindakan berkas berhasil (misalnya, berkas
mentransfer atau berkas batalkan).
227 Memasuki Mode pasif (h1, h2, h3, h4, p1, p2).
230 Pengguna login, lanjutkan.
250 Diminta tindakan berkas-baik saja, selesai.
257 "pathname" diciptakan.
331 Nama pengguna oke, membutuhkan password.
332 Perlu akun untuk login.
350 Diminta tindakan berkas menunggu informasi lebih lanjut.
421 Layanan tidak tersedia, menutup koneksi kontrol.
Ini mungkin balasan untuk perintah apapun jika layanan tahu itu
harus ditutup.
425 Tidak dapat membuka koneksi data.
426 Koneksi ditutup; Transfer dibatalkan.
450 Diminta tindakan berkas tidak diambil.
File tidak tersedia (misalnya, mengajukan sibuk).
451 tindakan Diminta dibatalkan: error lokal dalam pengolahan.
452 tindakan Diminta tidak diambil.
ruang penyimpanan tidak cukup dalam sistem.
Postel & Reynolds [Halaman 42]
RFC 959 Oktober 1985
File Transfer Protocol
500 Kesalahan sintaks, perintah tidak dikenal.
Ini mungkin termasuk kesalahan seperti baris perintah terlalu lama.
501 Kesalahan sintaks dalam parameter atau argumen.
502 Perintah tidak diimplementasikan.
503 urutan Bad perintah.
504 Perintah tidak diimplementasikan untuk parameter itu.
530 Tidak login.
532 Perlu akun untuk menyimpan file.
550 tindakan Diminta tidak diambil.
File tidak tersedia (misalnya, file tidak ditemukan, tidak ada akses).
551 tindakan Diminta dibatalkan: Jenis halaman diketahui.
552 Diminta tindakan berkas dibatalkan.
alokasi penyimpanan melebihi (untuk direktori saat ini atau
dataset).
553 tindakan Diminta tidak diambil.
File name tidak diperbolehkan.
5. SPESIFIKASI deklaratif
5.1. IMPLEMENTASI MINIMUM
Dalam rangka untuk membuat FTP bisa diterapkan tanpa pesan kesalahan perlu, yang
berikut implementasi minimum diperlukan untuk semua server:
TYPE - ASCII Non-print
MODE - Streaming
STRUKTUR - File, Rekam
PERINTAH - USER, QUIT, PORT,
TYPE, MODE, stru,
untuk nilai default
RETR, Stor,
NOOP.
Nilai default untuk parameter perpindahan adalah:
TYPE - ASCII Non-print
MODE - Streaming
Stru - Berkas
Semua host harus menerima atas sebagai default standar.
Postel & Reynolds [Halaman 43]
RFC 959 Oktober 1985
File Transfer Protocol
5.2. SAMBUNGAN
Protokol ini interpreter akan "mendengarkan" di Pelabuhan L.
pengguna atau pengguna protokol interpreter akan memulai full-duplex
koneksi kontrol. proses server-dan user- harus mengikuti
konvensi protokol Telnet sebagaimana ditentukan dalam
ARPA-Internet Protocol Handbook [1]. Server berada di bawah
kewajiban untuk menyediakan pengeditan baris perintah dan mungkin memerlukan
bahwa hal itu dilakukan di host pengguna. Koneksi kontrol akan
ditutup oleh server atas permintaan pengguna setelah semua transfer dan
balasan selesai.
Pengguna-DTP harus "mendengarkan" pada port data tertentu; ini mungkin
port default user (U) atau port tertentu dalam perintah PORT.
server akan memulai koneksi data dari default sendiri
port data (L-1) menggunakan port tertentu data pengguna. Arah
transfer dan port yang digunakan akan ditentukan oleh FTP
Perintah layanan.
Perhatikan bahwa semua pelaksanaan FTP harus mendukung transfer data menggunakan
port default, dan bahwa hanya PENGGUNA-PI dapat memulai penggunaan
port non-default.
Ketika data ditransfer antara dua server, A dan B (lihat
Gambar 2), pengguna-PI, C, set up koneksi kontrol dengan
kedua server PI. Salah satu server, mengatakan A, kemudian dikirim PASV a
perintah menyuruhnya untuk "mendengarkan" pada port data nya daripada
memulai koneksi ketika ia menerima perintah layanan transfer.
Ketika user-PI menerima pengakuan untuk perintah PASV,
yang meliputi identitas host dan port yang mendengarkan
pada, pengguna-PI kemudian mengirimkan port A, seorang, ke B dalam perintah PORT; Sebuah
balasan dikembalikan. Pengguna-PI maka dapat mengirimkan sesuai
Layanan perintah untuk A dan B. Server B memulai sambungan
dan transfer hasil. Perintah-balasan urutan terdaftar
bawah di mana pesan yang vertikal sinkron tapi
horizontal asynchronous:
Postel & Reynolds [Halaman 44]
RFC 959 Oktober 1985
File Transfer Protocol
User-PI - Server A User-PI - Server B
------------------ ------------------
C-> A: Connect C-> B: Connect
C-> A: PASV
A-> C: 227 Memasuki Mode pasif. A1, A2, A3, A4, a1, a2
C-> B: PORT A1, A2, A3, A4, a1, a2
B-> C: 200 Oke
C-> A: STOR C-> B: RETR
B-> A: Hubungkan ke HOST-A, PORT-a
Gambar 3
Sambungan data akan ditutup oleh server di bawah
kondisi yang dijelaskan dalam Bagian pada Membangun data
Koneksi. Jika koneksi data akan ditutup menyusul
transfer data di mana penutupan sambungan tidak diperlukan untuk
mengindikasikan akhir-of-file, server harus segera melakukannya.
Menunggu sampai setelah perintah transfer baru tidak diizinkan
karena user-proses akan telah diuji data
koneksi untuk melihat apakah perlu melakukan "mendengarkan"; (Ingat bahwa
pengguna harus "mendengarkan" pada port data tertutup SEBELUM mengirimkan
permintaan transfer). Untuk mencegah kondisi lomba di sini, server
mengirimkan balasan (226) setelah menutup sambungan data (atau jika
koneksi dibiarkan terbuka, "transfer file selesai" balas (250)
dan user-PI harus menunggu salah satu balasan ini sebelum
mengeluarkan perintah transfer baru).
Setiap saat baik pengguna atau server melihat bahwa sambungan
ditutup oleh pihak lain, harus segera membaca
Data yang tersisa antri pada sambungan dan menerbitkan dekat pada nya
sisi sendiri.
5.3. PERINTAH
Perintah adalah string karakter Telnet dikirimkan melalui
koneksi kontrol seperti yang dijelaskan dalam Bagian pada FTP Perintah.
Fungsi komando dan semantik dijelaskan dalam Bagian yang
Akses Kontrol Perintah, Transfer Parameter Perintah, FTP
Layanan Perintah, dan Aneka Perintah. Sintaks perintah
ditentukan di sini.
Perintah dimulai dengan kode perintah diikuti dengan argumen
bidang. Kode Perintah empat atau lebih sedikit karakter abjad.
Huruf besar dan kecil karakter abjad yang harus diperlakukan
identik. Dengan demikian, salah berikut ini mungkin mewakili
mengambil perintah:
Postel & Reynolds [Halaman 45]
RFC 959 Oktober 1985
File Transfer Protocol
RETR Retr retr retr retr
Hal ini juga berlaku untuk setiap simbol yang mewakili nilai-nilai parameter,
seperti A atau untuk ASCII TYPE. Kode perintah dan argumen
bidang dipisahkan oleh satu atau lebih spasi.
Bidang Argumen terdiri dari string karakter panjang variabel
berakhir dengan urutan karakter <CRLF> (Carriage Return, Line
Pakan) untuk representasi NVT-ASCII; untuk bahasa dinegosiasikan lainnya
akhir yang berbeda dari karakter garis dapat digunakan. Harus
mencatat bahwa server adalah untuk tidak mengambil tindakan sampai akhir baris
kode diterima.
sintaks ditentukan di bawah ini di NVT-ASCII. Semua karakter dalam
bidang argumen adalah karakter ASCII termasuk ASCII apapun
diwakili bilangan bulat desimal. kurung menunjukkan opsional
bidang argumen. Jika opsi tersebut tidak diambil, yang sesuai
default tersirat.
Postel & Reynolds [Halaman 46]
RFC 959 Oktober 1985
File Transfer Protocol
5.3.1. FTP PERINTAH
Berikut ini adalah perintah-perintah FTP:
PENGGUNA <SP> <username> <CRLF>
LULUS <SP> <password> <CRLF>
ACCT <SP> <akun-informasi> <CRLF>
CWD <SP> <path> <CRLF>
CDUP <CRLF>
SMNT <SP> <path> <CRLF>
QUIT <CRLF>
Rein <CRLF>
PORT <SP> <host-port> <CRLF>
PASV <CRLF>
TYPE <SP> <Jenis-code> <CRLF>
Stru <SP> <struktur-code> <CRLF>
MODE <SP> <modus-code> <CRLF>
RETR <SP> <path> <CRLF>
STOR <SP> <path> <CRLF>
Stou <CRLF>
APPE <SP> <path> <CRLF>
ALLO <SP> <desimal-integer>
[<SP> R <SP> <desimal-integer>] <CRLF>
SISA <SP> <penanda> <CRLF>
RNFR <SP> <path> <CRLF>
RNTO <SP> <path> <CRLF>
ABOR <CRLF>
DELE <SP> <path> <CRLF>
RMD <SP> <path> <CRLF>
MKD <SP> <path> <CRLF>
PWD <CRLF>
DAFTAR [<SP> <path>] <CRLF>
NLST [<SP> <path>] <CRLF>
SITE <SP> <string> <CRLF>
SYST <CRLF>
STAT [<SP> <path>] <CRLF>
BANTUAN [<SP> <string>] <CRLF>
NOOP <CRLF>
Postel & Reynolds [Halaman 47]
RFC 959 Oktober 1985
File Transfer Protocol
5.3.2. ARGUMEN COMMAND FTP
Sintaks bidang argumen di atas (menggunakan notasi BNF
mana yang berlaku) adalah:
<Username> :: = <string>
<Password> :: = <string>
<Akun-informasi> :: = <string>
<String> :: = <arang> | <Char> <string>
<Char> :: = salah satu 128 karakter ASCII kecuali <CR> dan
<LF>
<Penanda> :: = <pr-string>
<Pr-string> :: = <pr-char> | <Pr-char> <pr-string>
<Pr-char> :: = karakter yang dapat dicetak, setiap
Kode ASCII 33 sampai 126
<Byte-size> :: = <number>
<Host-port> :: = <host-number>, <port-number>
<Host-nomor> :: = <number>, <nomor>, <nomor>, <nomor>
<Port-number> :: = <number>, <nomor>
<Nomor> :: = setiap desimal bilangan bulat 1 sampai 255
<Form-code> :: = N | T | C
<Jenis-code> :: = A [<sp> <form-code>]
| E [<sp> <form-code>]
| saya
| L <sp> <byte-size>
<Struktur-code> :: = F | R | P
<Modus-code> :: = S | B | C
<Path> :: = <string>
<Desimal-integer> :: = bilangan bulat desimal
Postel & Reynolds [Halaman 48]
RFC 959 Oktober 1985
File Transfer Protocol
5.4. SEQUENCING OF PERINTAH dan balasan
Komunikasi antara pengguna dan server dimaksudkan untuk menjadi
bolak dialog. Dengan demikian, pengguna mengeluarkan perintah FTP dan
server merespon dengan balasan primer prompt. Pengguna harus
menunggu keberhasilan utama ini awal atau respon kegagalan sebelum
mengirimkan perintah lebih lanjut.
perintah tertentu membutuhkan jawaban kedua yang usernya
juga menunggu. balasan ini mungkin, misalnya, melaporkan kemajuan
atau penyelesaian transfer file atau penutupan data
koneksi. Mereka balasan sekunder untuk mengajukan perintah transfer.
Satu kelompok penting dari balasan informasi adalah koneksi
Salam pembuka. Dalam keadaan normal, server akan mengirim 220
menjawab, "menunggu masukan", ketika koneksi selesai. Itu
pengguna harus menunggu pesan ucapan ini sebelum mengirim
perintah. Jika server tidak dapat menerima masukan langsung, suatu
120 "delay diharapkan" balasan harus dikirim segera dan 220
menjawab ketika siap. Pengguna kemudian akan tahu untuk tidak menutup jika ada
penundaan.
Tanggapan spontan
Kadang-kadang "sistem" spontan memiliki pesan yang akan dikirim
untuk pengguna (biasanya semua pengguna). Misalnya, "Sistem akan turun
dalam 15 menit ". Tidak ada ketentuan dalam FTP untuk seperti
informasi spontan yang akan dikirim dari server ke pengguna.
Disarankan bahwa informasi tersebut akan antri di
Server-PI dan dikirim ke pengguna-PI di balasan berikutnya
(Mungkin membuatnya balasan multi-line).
Tabel di bawah ini berisi alternatif keberhasilan dan kegagalan balasan untuk
setiap perintah. Ini harus benar-benar dipatuhi; server mungkin
teks pengganti di balasan, namun makna dan tindakan tersirat
dengan nomor kode dan dengan spesifik perintah balasan urut
tidak dapat diubah.
Urutan perintah-Reply
Pada bagian ini, perintah-balasan urutan disajikan. Setiap
Perintah terdaftar dengan balasan yang mungkin terjadi; kelompok perintah yang
terdaftar bersama-sama. balasan awal terdaftar pertama (dengan
berhasil balasan mereka menjorok dan di bawah mereka), maka
positif dan penyelesaian negatif, dan akhirnya perantara
Postel & Reynolds [Halaman 49]
RFC 959 Oktober 1985
File Transfer Protocol
balasan dengan perintah yang tersisa dari urutan
berikut. daftar ini membentuk dasar bagi negara
diagram, yang akan disajikan secara terpisah.
koneksi Pendirian
120
220
220
421
Masuk
PENGGUNA
230
530
500, 501, 421
331, 332
LULUS
230
202
530
500, 501, 503, 421
332
ACCT
230
202
530
500, 501, 503, 421
CWD
250
500, 501, 502, 421, 530, 550
CDUP
200
500, 501, 502, 421, 530, 550
SMNT
202, 250
500, 501, 502, 421, 530, 550
Keluar
KENDALI
120
220
220
421
500, 502
BERHENTI
221
500
Postel & Reynolds [Halaman 50]
RFC 959 Oktober 1985
File Transfer Protocol
parameter transfer
PELABUHAN
200
500, 501, 421, 530
PASV
227
500, 501, 502, 421, 530
MODE
200
500, 501, 504, 421, 530
MENGETIK
200
500, 501, 504, 421, 530
stru
200
500, 501, 504, 421, 530
perintah tindakan File
ALLO
200
202
500, 501, 504, 421, 530
BERISTIRAHAT
500, 501, 502, 421, 530
350
STOR
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
Stou
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
RETR
125, 150
(110)
226, 250
425, 426, 451
450, 550
500, 501, 421, 530
Postel & Reynolds [Halaman 51]
RFC 959 Oktober 1985
File Transfer Protocol
DAFTAR
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
NLST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
APPE
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 550, 452, 553
500, 501, 502, 421, 530
RNFR
450, 550
500, 501, 502, 421, 530
350
RNTO
250
532, 553
500, 501, 502, 503, 421, 530
DELE
250
450, 550
500, 501, 502, 421, 530
RMD
250
500, 501, 502, 421, 530, 550
MKD
257
500, 501, 502, 421, 530, 550
PWD
257
500, 501, 502, 421, 550
ABOR
225, 226
500, 501, 502, 421
Postel & Reynolds [Halaman 52]
RFC 959 Oktober 1985
File Transfer Protocol
perintah informasi
SYST
215
500, 501, 502, 421
STAT
211, 212, 213
450
500, 501, 502, 421, 530
MEMBANTU
211, 214
500, 501, 502, 421
perintah Miscellaneous
SITE
200
202
500, 501, 530
NOOP
200
500 421
Postel & Reynolds [Halaman 53]
RFC 959 Oktober 1985
File Transfer Protocol
6. DIAGRAM STATE
Berikut kami sajikan diagram negara untuk berpikiran FTP sangat sederhana
pelaksanaan. Hanya digit pertama dari kode yg digunakan.
Ada satu diagram negara untuk setiap kelompok perintah FTP atau perintah
urutan.
Pengelompokan perintah ditentukan dengan membangun model untuk
setiap perintah kemudian mengumpulkan bersama-sama perintah dengan struktural
model identik.
Untuk setiap perintah atau perintah urut ada tiga kemungkinan
Hasil: Keberhasilan (S), kegagalan (F), dan kesalahan (E). Di negara bagian
diagram di bawah ini kita menggunakan simbol B untuk "mulai", dan simbol W untuk
"Menunggu jawaban".
Kami pertama kali menyajikan diagram yang mewakili kelompok terbesar dari FTP
perintah:
1,3 + --- +
-----------> | E |
| + --- +
|
+ --- + Cmd + --- + 2 + --- +
| B | ----------> | W | ----------> | S |
+ --- + + --- + + --- +
|
| 4,5 + --- +
-----------> | F |
+ --- +
Diagram ini model perintah:
ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, stru, dan TYPE.
Postel & Reynolds [Halaman 54]
RFC 959 Oktober 1985
File Transfer Protocol
Kelompok besar lainnya dari perintah diwakili oleh sangat mirip
diagram:
3 + --- +
-----------> | E |
| + --- +
|
+ --- + Cmd + --- + 2 + --- +
| B | ----------> | W | ----------> | S |
+ --- + ---> + --- + + --- +
| | |
| | | 4,5 + --- +
| 1 | -----------> | F |
----- + --- +
Diagram ini model perintah:
APPE, LIST, NLST, Rein, RETR, Stor, dan Stou.
Perhatikan bahwa model kedua ini juga bisa digunakan untuk mewakili pertama
kelompok perintah, satu-satunya perbedaan adalah bahwa dalam kelompok pertama
100 seri balasan yang tak terduga dan karena itu diperlakukan sebagai kesalahan,
sedangkan kelompok kedua mengharapkan (beberapa mungkin memerlukan) 100 seri balasan.
Ingat bahwa pada sebagian besar, satu seri 100 balasan diperbolehkan per perintah.
Sisanya urutan perintah diagram Model, mungkin yang paling sederhana
ini adalah urutan mengubah nama:
+ --- + RNFR + --- + 1,2 + --- +
| B | ----------> | W | ----------> | E |
+ --- + + --- + -> + --- +
| | |
3 | | 4,5 |
-------------- ------ |
| | | + --- +
| -------------> | S |
| | 1,3 | | + --- +
| 2 | --------
| | | |
V | | |
+ --- + RNTO + --- + 4,5 -----> + --- +
| | ----------> | W | ----------> | F |
+ --- + + --- + + --- +
Postel & Reynolds [Halaman 55]
RFC 959 Oktober 1985
File Transfer Protocol
Diagram berikutnya adalah model sederhana dari perintah Restart:
+ --- + SISA + --- + 1,2 + --- +
| B | ----------> | W | ----------> | E |
+ --- + + --- + -> + --- +
| | |
3 | | 4,5 |
-------------- ------ |
| | | + --- +
| -------------> | S |
| | 3 | | + --- +
| 2 | --------
| | | |
V | | |
+ --- + Cmd + --- + 4,5 -----> + --- +
| | ----------> | W | ----------> | F |
+ --- + -> + --- + + --- +
| |
| 1 |
------
Mana "cmd" adalah APPE, Stor, atau RETR.
Kami mencatat bahwa di atas tiga model serupa. Restart berbeda
dari Rename dua hanya dalam pengobatan 100 seri balasan di
tahap kedua, sementara kelompok kedua mengharapkan (beberapa mungkin memerlukan)
100 balasan seri. Ingat bahwa pada sebagian besar, satu seri 100 balasan adalah
diizinkan per perintah.
Postel & Reynolds [Halaman 56]
RFC 959 Oktober 1985
File Transfer Protocol
Diagram yang paling rumit adalah untuk urutan Login:
1
+ --- + USER + --- + -------------> + --- +
| B | ----------> | W | 2 ----> | E |
+ --- + + --- + ------ | -> + --- +
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| | | | |
| --------- |
| 1 | | | |
V | | | |
+ --- + LULUS + --- + 2 | ------> + --- +
| | ----------> | W | -------------> | S |
+ --- + + --- + ----------> + --- +
| | | | |
3 | | 4,5 | | |
-------------- -------- |
| | | | |
| | | | |
| -----------
| 1,3 | | | |
V | 2 | | |
+ --- + ACCT + --- + - | -----> + --- +
| | ----------> | W | 4,5 --------> | F |
+ --- + + --- + -------------> + --- +
Postel & Reynolds [Halaman 57]
RFC 959 Oktober 1985
File Transfer Protocol
Akhirnya, kami menyajikan diagram umum yang dapat digunakan untuk model
perintah dan membalas interchange:
------------------------------------
| |
Mulailah | |
| V |
| + --- + Cmd + --- + 2 + --- + |
-> | | -------> | | ----------> | | |
| | | W | | S | ----- |
-> | | -> | | ----- | | |
| + --- + | + --- + 4,5 | + --- + |
| | | | | | |
| | | 1 | | 3 | + --- + |
| | | | | | | | |
| | ---- | ----> | F | -----
| | | | |
| | | + --- +
-------------------
|
|
V
Akhir
Postel & Reynolds [Halaman 58]
RFC 959 Oktober 1985
File Transfer Protocol
7. KHAS FTP SKENARIO
Pengguna di host U ingin mentransfer file ke / dari host S:
Secara umum, pengguna akan berkomunikasi dengan server melalui mediasi yang
Proses user-FTP. berikut mungkin skenario khas. Itu
user-FTP prompt ditampilkan dalam tanda kurung, '---->' mewakili
perintah dari host U untuk menjadi tuan rumah S, dan '<----' merupakan balasan dari
tuan rumah S untuk menjadi tuan rumah U.
PERINTAH LOKAL OLEH PENGGUNA ACTION TERLIBAT
ftp (host) Multics <CR> Connect untuk menjadi tuan rumah S, pelabuhan L,
membangun koneksi kontrol.
<---- 220 Layanan siap <CRLF>.
nama pengguna Doe <CR> PENGGUNA Doe <CRLF> ---->
<---- 331 nama pengguna ok,
membutuhkan password <CRLF>.
sandi bergumam <CR> LULUS bergumam <CRLF> ---->
<---- 230 Pengguna login <CRLF>.
mengambil (jenis lokal) ASCII <CR>
(Pathname lokal) uji 1 <CR> User-FTP membuka file lokal di ASCII.
(Untuk. Pathname) test.pl1 <CR> RETR test.pl1 <CRLF> ---->
<---- 150 Status Berkas-baik saja;
tentang membuka data
koneksi <CRLF>.
Server membuat sambungan data
untuk U. pelabuhan
<---- 226 sambungan Penutupan data,
transfer file berhasil <CRLF>.
Jenis Gambar <CR> TYPE I <CRLF> ---->
<---- 200 Command OK <CRLF>
toko (jenis lokal) image <CR>
(Lokal pathname) file dump <CR> User-FTP membuka file lokal di Gambar.
(For.pathname)> UDD> cn> fd <CR> STOR> UDD> cn> fd <CRLF> ---->
<---- 550 Akses ditolak <CRLF>
Hentikan QUIT <CRLF> ---->
Server menutup semua
koneksi.
8. CONNECTION PENDIRIAN
Koneksi kontrol FTP didirikan melalui TCP antara pengguna
pelabuhan proses U dan port proses server L. protokol ini adalah
ditugaskan port layanan 21 (25 oktal), yaitu L = 21.
Postel & Reynolds [Halaman 59]
RFC 959 Oktober 1985
File Transfer Protocol
LAMPIRAN I - PAGE STRUKTUR
Kebutuhan FTP untuk mendukung struktur halaman berasal terutama dari
kebutuhan untuk mendukung transmisi yang efisien dari file antara TOPS-20
sistem, terutama file yang digunakan oleh NLS.
Sistem file TOPS-20 didasarkan pada konsep halaman. Itu
sistem operasi yang paling efisien di memanipulasi file sebagai halaman.
Sistem operasi menyediakan antarmuka ke sistem file sehingga
banyak aplikasi melihat file sebagai aliran sekuensial karakter.
Namun, beberapa aplikasi menggunakan struktur halaman yang mendasari
langsung, dan beberapa di antaranya membuat file berlubang.
Sebuah file TOPS-20 disk yang terdiri dari empat hal: a pathname, halaman
tabel, (mungkin kosong) set halaman, dan satu set atribut.
pathname ditentukan dalam RETR atau STOR perintah. Itu termasuk
nama direktori, nama file, nama file ekstensi, dan generasi
jumlah.
Halaman tabel berisi hingga 2 ** 18 entri. Setiap entri mungkin
KOSONG, atau mungkin menunjuk ke halaman. Jika tidak kosong, ada juga
beberapa halaman khusus akses bit; tidak semua halaman file perlu memiliki
perlindungan akses yang sama.
Sebuah halaman adalah satu set bersebelahan 512 kata masing-masing 36 bit.
Atribut file, di Blok Berkas Descriptor (FDB),
berisi hal-hal seperti waktu penciptaan, menulis waktu, membaca waktu, penulis
byte-size, akhir-of-file pointer, menghitung dari membaca dan menulis, backup
nomor pita sistem, dll
Perhatikan bahwa tidak ada persyaratan bahwa entri di tabel halaman menjadi
berdekatan. Mungkin ada yang kosong slot tabel halaman antara diduduki
yang. Juga, akhir file pointer hanya nomor. Tidak ada
persyaratan bahwa di titik sebenarnya pada datum "terakhir" dalam file.
Biasa sekuensial I / O panggilan di TOPS-20 akan menyebabkan akhir file
pointer dibiarkan setelah datum terakhir yang ditulis, tapi operasi lainnya
dapat menyebabkan tidak begitu, jika sistem pemrograman tertentu sehingga
membutuhkan.
Bahkan, di kedua kasus-kasus khusus, "berlubang" file dan
end-of-file pointer tidak pada akhir file, terjadi dengan data NLS
file.
Postel & Reynolds [Halaman 60]
RFC 959 Oktober 1985
File Transfer Protocol
The TOPS-20 paged file dapat dikirim dengan parameter FTP transfer:
TYPE L 36, stru P, dan MODE S (pada kenyataannya, modus apapun dapat digunakan).
Setiap halaman informasi memiliki header. Setiap bidang header, yang merupakan
byte logis, adalah TOPS-20 kata, karena TYPE adalah L 36.
Bidang header:
Kata 0: header Panjang.
Panjang header 5.
Kata 1: Halaman Index.
Jika data adalah halaman file disk, ini adalah jumlah yang
Halaman Peta halaman file. halaman kosong (lubang) di file
hanya tidak dikirim. Perhatikan bahwa lubang TIDAK sama sebagai
Halaman dari nol.
Kata 2: Data Panjang.
Jumlah kata data dalam halaman ini, berikut header.
Dengan demikian, total panjang unit transmisi Header
Panjang ditambah panjang data.
Kata 3: Halaman Type.
Sebuah kode untuk jenis potongan ini. Sebuah halaman data adalah tipe 3,
halaman FDB adalah tipe 2.
Kata 4: PT Access Control.
Akses bit yang berhubungan dengan halaman di halaman file
peta. (Kuantitas kata penuh ini dimasukkan ke AC2 dari SPACS oleh
program membaca dari net ke disk.)
Setelah header adalah data Panjang kata data. Data Panjang adalah
Saat ini baik 512 untuk halaman data atau 31 untuk FDB. Trailing
nol di halaman file disk dapat dibuang, membuat Data Length kurang
dari 512 dalam kasus itu.
Postel & Reynolds [Halaman 61]
RFC 959 Oktober 1985
File Transfer Protocol
LAMPIRAN II - PERINTAH DIREKTORI
Sejak UNIX memiliki struktur direktori seperti pohon di mana direktori
adalah sebagai mudah untuk memanipulasi file sebagai biasa, hal ini berguna untuk memperluas
server FTP pada mesin ini untuk memasukkan perintah yang berhubungan dengan
penciptaan direktori. Karena ada host lain pada
ARPA-Internet yang memiliki direktori seperti pohon (termasuk TOPS-20 dan
Multics), perintah ini adalah sebagai umum mungkin.
Empat perintah direktori telah ditambahkan ke FTP:
MKD pathname
Membuat direktori dengan nama "path".
RMD pathname
Menghapus direktori dengan nama "path".
PWD
Cetak bekerja saat nama direktori.
CDUP
Ubah ke induk dari direktori kerja saat ini.
The "pathname" argumen harus dibuat (dihapus) sebagai
subdirektori dari direktori kerja saat ini, kecuali "pathname"
string berisi informasi yang cukup untuk menentukan lain ke
Server, misalnya, "pathname" adalah nama path absolut (di UNIX dan
Multics), atau pathname adalah sesuatu seperti "<abso.lute.path>" untuk
TOPS-20.
KODE REPLY
Perintah CDUP adalah kasus khusus dari CWD, dan termasuk ke
menyederhanakan pelaksanaan program untuk mentransfer direktori
pohon antara sistem operasi memiliki sintaks yang berbeda untuk
penamaan direktori induk. Kode balasan untuk CDUP menjadi
identik dengan kode balasan dari CWD.
Kode balasan untuk RMD identik dengan kode balasan untuk nya
analog mengajukan, DELE.
Kode balasan untuk MKD, bagaimanapun, adalah sedikit lebih rumit. SEBUAH
baru direktori yang dibuat mungkin akan menjadi obyek masa depan
Postel & Reynolds [Halaman 62]
RFC 959 Oktober 1985
File Transfer Protocol
perintah CWD. Sayangnya, argumen untuk MKD tidak mungkin selalu
argumen cocok untuk CWD. Hal ini terjadi, misalnya, ketika
a TOPS-20 subdirektori dibuat dengan memberikan hanya subdirektori
nama. Artinya, dengan server FTP TOPS-20, urutan perintah
MKD mydir
CWD mydir
akan gagal. Direktori baru hanya dapat disebut oleh-nya
"Mutlak" nama; misalnya, jika perintah MKD di atas dikeluarkan sementara
terhubung ke direktori <DFRANKLIN>, subdirektori baru
hanya bisa disebut dengan nama <DFRANKLIN.MYDIR>.
Bahkan pada UNIX dan Multics, bagaimanapun, argumen yang diberikan kepada MKD mungkin
tidak cocok. Jika itu adalah "relatif" path (yaitu, pathname
yang ditafsirkan relatif terhadap direktori saat ini), pengguna
akan perlu berada di direktori saat yang sama untuk mencapai
subdirektori. Tergantung pada aplikasi, ini mungkin
nyaman. Hal ini tidak sangat kuat dalam hal apapun.
Untuk mengatasi masalah ini, setelah berhasil menyelesaikan sebuah MKD
perintah, server harus kembali garis dalam bentuk:
257 <spasi> "<directory-nama>" <spasi> <komentar>
Artinya, server akan memberitahu pengguna apa string untuk digunakan saat
mengacu pada direktori yang dibuat. Nama direktori dapat
berisi karakter apapun; tertanam tanda kutip ganda harus melarikan diri dengan
tanda kutip ganda ( "kutipan-penggandaan" konvensi).
Misalnya, pengguna terhubung ke direktori / usr / dm, dan menciptakan
subdirektori, bernama pathname:
CWD / usr / dm
200 direktori berubah ke / usr / dm
MKD pathname
257 "/ usr / dm / pathname" direktori yang dibuat
Contoh dengan kutipan ganda tertanam:
MKD foo "bar
257 "/ usr / dm / foo" "bar" direktori yang dibuat
CWD / usr / dm / foo "bar
200 direktori berubah ke / usr / dm / foo "bar
Postel & Reynolds [Halaman 63]
RFC 959 Oktober 1985
File Transfer Protocol
Keberadaan sebelumnya sebuah subdirektori dengan nama yang sama adalah
kesalahan, dan server harus mengembalikan "akses ditolak" balasan error
dalam hal itu.
CWD / usr / dm
200 direktori berubah ke / usr / dm
MKD pathname
521 - "/ usr / dm / pathname" direktori sudah ada;
521 tidak mengambil tindakan.
Balasan kegagalan bagi MKD analog dengan menciptakan file-nya
sepupu, Stor. Juga, sebuah "akses ditolak" kembali diberikan jika file
nama dengan nama yang sama dengan subdirektori akan bertentangan dengan
penciptaan subdirektori (ini adalah masalah pada UNIX, tetapi
tidak harus satu di TOPS-20).
Dasarnya karena perintah PWD mengembalikan jenis yang sama
informasi sebagai perintah MKD berhasil, PWD sukses
perintah menggunakan kode 257 balasan juga.
kehalusan
Karena perintah ini akan sangat berguna dalam mentransfer
sub pohon dari satu komputer ke komputer lain, hati-hati mengamati bahwa
Argumen untuk MKD harus ditafsirkan sebagai sub-direktori dari
direktori kerja saat ini, kecuali berisi informasi yang cukup
untuk host tujuan untuk memberitahu sebaliknya. Sebuah hipotesis
contoh penggunaannya dalam dunia TOPS-20:
CWD <some.where>
200 direktori Kerja berubah
MKD overrainbow
257 "<some.where.overrainbow>" direktori yang dibuat
CWD overrainbow
431 Tidak ada direktori tersebut
CWD <some.where.overrainbow>
200 direktori Kerja berubah
CWD <some.where>
200 direktori Kerja diubah menjadi <some.where>
MKD <ambigu>
257 "<ambigu>" direktori yang dibuat
CWD <ambigu>
Perhatikan bahwa contoh pertama menghasilkan sebuah subdirektori dari
direktori terhubung. Sebaliknya, argumen di kedua
Misalnya berisi informasi yang cukup untuk TOPS-20 untuk memberitahu bahwa
Postel & Reynolds [Halaman 64]
RFC 959 Oktober 1985
File Transfer Protocol
<Ambigu> directory adalah direktori tingkat atas. Perhatikan juga bahwa
dalam contoh pertama pengguna "melanggar" protokol dengan
mencoba untuk mengakses direktori yang baru dibuat dengan nama
selain yang dikembalikan oleh TOPS-20. Masalah bisa memiliki
mengakibatkan hal ini telah ada menjadi <overrainbow> direktori;
ini adalah ambiguitas yang melekat di beberapa TOPS-20 implementasi.
Pertimbangan serupa berlaku untuk perintah RMD. Intinya adalah
ini: kecuali untuk melakukannya akan melanggar konvensi host untuk
yang menunjukkan relatif dibandingkan nama path absolut, tuan rumah harus memperlakukan
operan dari MKD dan RMD perintah sebagai subdirektori. Itu
257 membalas perintah MKD harus selalu berisi mutlak
pathname dari direktori yang dibuat.
Postel & Reynolds [Halaman 65]
RFC 959 Oktober 1985
File Transfer Protocol
LAMPIRAN III - RFC pada FTP
Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
MIT-Project MAC, 16 April 1971.
Harslem, Eric, dan John Heafner, "Komentar RFC 114 (File
Transfer Protocol) ", RFC 141 (NIC 6726), RAND, 29 April 1971.
Bhushan, Abhay, et al, "File Transfer Protocol", RFC 172
(NIC 6794), MIT-Project MAC, 23 Juni 1971.
Braden, Bob, "Komentar DTP dan FTP Proposal", RFC 238 (NIC 7663),
UCLA / CCN, 29 September 1971.
Bhushan, Abhay, et al, "File Transfer Protocol", RFC 265
(NIC 7813), MIT-Project MAC, 17 November 1971.
McKenzie, Alex, "A Disarankan Penambahan File Transfer Protocol",
RFC 281 (NIC 8163), BBN, 8 Desember 1971.
Bhushan, Abhay, "Penggunaan" Set Tipe Data "Transaksi File
Mentransfer Protocol ", RFC 294 (NIC 8304), MIT-Project MAC,
25 Januari 1972.
Bhushan, Abhay, "File Transfer Protocol", RFC 354 (NIC 10596),
MIT-Project MAC, 8 Juli 1972.
Bhushan, Abhay, "Komentar File Transfer Protocol (RFC 354)",
RFC 385 (NIC 11357), MIT-Project MAC, 18 Agustus 1972.
Hicks, Greg, "FTP Pengguna Dokumentasi", RFC 412 (NIC 12404), Utah,
27 November 1972.
Bhushan, Abhay, "File Transfer Protocol (FTP) Status dan lebih lanjut
Komentar ", RFC 414 (NIC 12.406), MIT-Project MAC, 20 November 1972.
Braden, Bob, "Komentar File Transfer Protocol", RFC 430
(NIC 13.299), UCLA / KKN, 7 Februari 1973.
Thomas, Bob, dan Bob Clements, "FTP Server-Server Interaksi",
RFC 438 (NIC 13770), BBN, 15 Januari 1973.
Braden, Bob, "Print File di FTP", RFC 448 (NIC 13.299), UCLA / KKN,
27 Februari 1973.
McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14.333), BBN,
16 Februari 1973.
Postel & Reynolds [Halaman 66]
RFC 959 Oktober 1985
File Transfer Protocol
Bressler, Bob, dan Bob Thomas, "Mail Retrieval via FTP", RFC 458
(NIC 14.378), BBN-NET dan BBN-TENEX, 20 Februari 1973.
Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17.759), BBN,
12 Juli 1973.
Krilanovich, Mark, dan George Gregg, "Komentar File Transfer
Protokol ", RFC 607 (NIC 21.255), UCSB, 7 Januari 1974.
Pogran, Ken, dan Nancy Neigus, "Respon untuk RFC 607 - Komentar
File Transfer Protocol ", RFC 614 (NIC 21.530), BBN, 28 Januari 1974.
Krilanovich, Mark, George Gregg, Wayne Hathaway, dan Jim Putih,
"Komentar dari File Transfer Protocol", RFC 624 (NIC 22.054), UCSB,
Ames Research Center, SRI-ARC, 28 Februari 1974.
Bhushan, Abhay, "FTP Komentar dan Respon untuk RFC 430", RFC 463
(NIC 14.573), MIT-DMCG, 21 Februari 1973.
Braden, Bob, "FTP Kompresi Data", RFC 468 (NIC 14.742), UCLA / KKN,
8 Maret 1973.
Bhushan, Abhay, "FTP dan Jaringan Mail System", RFC 475 (NIC 14.919),
MIT-DMCG, 6 Maret 1973.
Bressler, Bob, dan Bob Thomas "FTP Server-Server Interaksi - II",
RFC 478 (NIC 14.947), BBN-NET dan BBN-TENEX, 26 Maret 1973.
Putih, Jim, "Penggunaan FTP oleh NIC Journal", RFC 479 (NIC 14.948),
SRI-ARC, 8 Maret 1973.
Putih, Jim, "Host-Dependent FTP Parameter", RFC 480 (NIC 14.949),
SRI-ARC, 8 Maret 1973.
Padlipsky, Mike, "Sebuah Soal FTP Command-Penamaan", RFC 506
(NIC 16.157), MIT-Multics, 26 Juni 1973.
Hari, John, "Memo ke FTP Group (Proposal File Access Protocol)",
RFC 520 (NIC 16.819), Illinois, 25 Juni 1973.
Merryman, Robert, "The UCSD-CC Server-FTP Fasilitas", RFC 532
(NIC 17451), UCSD-CC, 22 Juni 1973.
Braden, Bob, "TENEX FTP Masalah", RFC 571 (NIC 18.974), UCLA / KKN,
15 November 1973.
Postel & Reynolds [Halaman 67]
RFC 959 Oktober 1985
File Transfer Protocol
McKenzie, Alex, dan Jon Postel, "Telnet dan Implementasi FTP -
Jadwal Perubahan ", RFC 593 (NIC 20.615), BBN dan MITRE,
29 November 1973.
Sussman, Julie, "FTP Kesalahan Kode Penggunaan untuk Mail Lebih Handal
Layanan ", RFC 630 (NIC 30237), BBN, 10 April 1974.
Postel, Jon, "Revisi FTP Reply Codes", RFC 640 (NIC 30.843),
UCLA / NMC, 5 Juni 1974.
Harvey, Brian, "Meninggalkan Nah Cukup Alone", RFC 686 (NIC 32.481),
SU-AI, 10 Mei 1975.
Harvey, Brian, "One More Try dari FTP", RFC 691 (NIC 32700), SU-AI,
28 Mei 1975.
Lieb, J., "CWD Command dari FTP", RFC 697 (NIC 32963), 14 Juli 1975.
Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42.217), SRI-KL,
31 Oktober 1977.
Harrenstien, Ken, "FTP Extension: XRSQ / XRCP", RFC 743 (NIC 42.758),
SRI-KL, 30 Desember 1977.
Lebling, P. David, "Survei FTP Mail dan MLFL", RFC 751, MIT,
10 Desember 1978.
Postel, Jon, "File Transfer Protocol Keterangan", RFC 765, ISI,
Juni 1980.
Mankins, David, Dan Franklin, dan Buzz Owen, "Direktori Berorientasi FTP
Perintah ", RFC 776, BBN, Desember 1980.
Padlipsky, Michael, "FTP Unik-Dinamakan Toko Command", RFC 949, MITRE,
Juli 1985.
Postel & Reynolds [Halaman 68]
RFC 959 Oktober 1985
File Transfer Protocol
REFERENSI
[1] Feinler, Elizabeth, "Internet Protocol Transisi Workbook",
Pusat Informasi Jaringan, SRI International, Maret 1982.
[2] Postel, Jon, "Transmission Control Protocol - Internet DARPA
Program Protocol Keterangan ", RFC 793, DARPA, September 1981.
[3] Postel, Jon, dan Joyce Reynolds, "Telnet Protocol
Spesifikasi ", RFC 854, ISI, Mei 1983.
[4] "Bilangan Ditugaskan" Reynolds, Joyce, dan Jon Postel,, RFC 943,
ISI, April 1985.
Postel & Reynolds [Halaman 69]
Berikut ada RFC SAMBA versi Bahasa Indonesia
Jaringan Kelompok Kerja L. Howard
Permintaan Komentar: 2307 Konsultan Independen
Kategori: Eksperimental Maret 1998
Pendekatan untuk Menggunakan LDAP sebagai Jaringan Informasi Layanan
Status Memo ini
Memo ini mendefinisikan Protocol Eksperimental untuk Internet
masyarakat. Tidak menentukan standar internet apapun.
Diskusi dan saran untuk perbaikan yang diminta.
Distribusi memo ini tidak terbatas.
Pemberitahuan hak cipta
Copyright (C) The Internet Society (1998). Seluruh hak cipta.
Abstrak
Dokumen ini menjelaskan mekanisme eksperimental untuk pemetaan
entitas yang terkait dengan sistem UNIX TCP / IP dan ke X.500 [X500]
entri sehingga mereka dapat diselesaikan dengan Direktori Ringan
Access Protocol [RFC2251]. Satu set jenis atribut dan objek
Kelas diusulkan, bersama dengan pedoman khusus untuk menafsirkan
mereka.
Tujuannya adalah untuk membantu penyebaran LDAP sebagai
nameservice organisasi. Tidak ada solusi yang diusulkan dimaksudkan sebagai
standar untuk Internet. Sebaliknya, diharapkan seorang jenderal
konsensus akan muncul sebagai untuk solusi yang tepat untuk seperti
masalah, yang akhirnya untuk adopsi standar. Itu
Mekanisme yang diusulkan telah dilaksanakan dengan beberapa keberhasilan.
1. Latar Belakang dan Motivasi
UNIX (R) sistem operasi, dan turunannya (khusus,
mereka yang mendukung TCP / IP dan sesuai dengan X / Open Single UNIX
spesifikasi [XOPEN]) memerlukan sarana mencari entitas, oleh
pencocokan mereka terhadap kriteria pencarian atau dengan enumerasi. (Lain
sistem operasi yang mendukung TCP / IP dapat memberikan beberapa cara
menyelesaikan beberapa entitas ini. Skema ini berlaku untuk orang-orang
lingkungan juga.)
entitas ini termasuk pengguna, kelompok, layanan IP (yang memetakan nama ke
port IP dan protokol, dan sebaliknya), protokol IP (yang peta
nama untuk nomor IP protokol dan sebaliknya), RPC (yang memetakan nama
untuk ONC Remote Procedure Call [RFC1057] angka dan sebaliknya), NIS
Howard Eksperimental [Halaman 1]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
Netgroups, booting informasi (parameter boot dan alamat MAC
pemetaan), filesystem gunung, IP host dan jaringan, dan surat RFC822
alias.
permintaan resolusi dilakukan melalui satu set fungsi C, tersedia
di C library sistem UNIX. Misalnya, utilitas sistem UNIX
"Ls", yang menyebutkan isi dari sebuah direktori filesystem, penggunaan
C fungsi library getpwuid () untuk memetakan ID pengguna untuk login
nama. Setelah permintaan dibuat, diselesaikan dengan menggunakan "nameservice"
yang didukung oleh perpustakaan klien. nameservice mungkin, di
yang paling sederhana, kumpulan file dalam sistem file lokal yang
dibuka dan dicari oleh perpustakaan C. nameservices umum lainnya
termasuk Network Information Service (NIS) dan Nama Domain
System (DNS). (Yang terakhir ini biasanya digunakan untuk menyelesaikan host,
layanan dan jaringan.) Kedua nameservices ini memiliki keuntungan
menjadi didistribusikan dan sehingga memungkinkan seperangkat entitas menjadi
dibagi di antara banyak klien.
LDAP adalah didistribusikan, layanan direktori hirarki protokol akses
yang digunakan untuk mengakses repositori dari pengguna dan jaringan, lainnya
entitas terkait. Karena LDAP sering tidak terintegrasi dengan
sistem operasi host, informasi seperti pengguna mungkin perlu
terus baik di LDAP dan dalam nameservice sistem operasi yang didukung
seperti NIS. Dengan menggunakan LDAP sebagai sarana utama untuk menyelesaikan
entitas ini, masalah redundansi ini diminimalkan dan
skalabilitas dari LDAP dapat dimanfaatkan. (Sebagai perbandingan, layanan NIS
berdasarkan flat file tidak memiliki skalabilitas atau diperpanjang
LDAP atau X.500.)
Kelas-kelas objek dan atribut yang didefinisikan di bawah ini cocok untuk
mewakili entitas tersebut dalam bentuk yang kompatibel dengan
LDAP dan direktori X.500 layanan.
2. Masalah Umum
2.1. Terminologi
kata kunci "HARUS", "HARUS", dan "MUNGKIN" digunakan dalam dokumen ini adalah
ditafsirkan seperti yang dijelaskan dalam [RFC2119].
Untuk tujuan dokumen ini, istilah "nameservice" mengacu pada
layanan, seperti NIS atau file datar, yang digunakan oleh operasi
sistem untuk menyelesaikan entitas dalam konteks penamaan tunggal, lokal.
Kontras ini dengan "layanan direktori" seperti LDAP, yang mendukung
skema extensible dan konteks penamaan beberapa.
Howard Eksperimental [Page 2]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
Istilah "entitas NIS yang berhubungan" secara luas mengacu pada entitas yang
biasanya diselesaikan dengan menggunakan Network Information Service. (NIS adalah
sebelumnya dikenal sebagai YP.) Menyebarkan LDAP untuk menyelesaikan entitas
tidak berarti bahwa NIS digunakan, sebagai gateway atau sebaliknya. Di
khususnya, host dan kelas jaringan yang umum berlaku,
dan dapat diimplementasikan pada sistem yang ingin menggunakan LDAP atau X.500
untuk tuan rumah dan resolusi jaringan.
The "DUA" (direktori agen pengguna) mengacu pada query LDAP client
entitas ini, seperti LDAP untuk NIS gateway atau perpustakaan C. Itu
"Klien" mengacu pada aplikasi yang akhirnya membuat penggunaan
Informasi dikembalikan oleh resolusi. Hal ini tidak relevan apakah
DUA dan klien berada dalam ruang alamat yang sama. Tindakan
yang DUA membuat informasi ini kepada klien disebut
"Publikasi".
Untuk menghindari kebingungan, istilah "nama login" mengacu login pengguna
Nama (menjadi nilai atribut uid) dan istilah "user ID"
mengacu pada nomor identifikasi bulat dia pengguna (menjadi nilai
atribut uidNumber).
Frase "menyelesaikan suatu entitas" dan "resolusi entitas" merujuk
masing-masing untuk pencacahan entitas terkait NIS dari jenis tertentu, dan
pencocokan mereka terhadap kriteria pencarian tertentu. Satu atau lebih entitas
dikembalikan sebagai hasil dari sukses "resolusi" (a "match"
operasi hanya akan kembali satu entitas).
Penggunaan istilah UNIX tidak memberi atas ini skema
dukungan dari pemilik merek dagang UNIX. Bila perlu,
Istilah "TCP / IP entitas" digunakan untuk merujuk pada protokol, layanan, host,
dan jaringan, dan istilah "UNIX entitas" untuk melengkapi nya. (Itu
kategori pertama tidak mandat sistem operasi host yang mendukung
antarmuka yang diperlukan untuk menyelesaikan entitas UNIX.)
OIDs didefinisikan di bawah berasal dari iso (1) org (3) dod (6)
internet (1) direktori (1) nisSchema (1).
2.2. atribut
Atribut dan kelas didefinisikan dalam dokumen ini dirangkum
di bawah.
Atribut berikut didefinisikan dalam dokumen ini:
uidNumber
gidNumber
gecos
HomeDirectory
Howard Experimental [Page 3]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
loginShell
shadowLastChange
shadowMin
shadowMax
shadowWarning
shadowInactive
shadowExpire
shadowFlag
memberUid
memberNisNetgroup
nisNetgroupTriple
ipServicePort
ipServiceProtocol
ipProtocolNumber
oncRpcNumber
ipHostNumber
ipNetworkNumber
ipNetmaskNumber
alamat MAC
bootParameter
bootfile
nisMapName
nisMapEntry
Selain itu, beberapa atribut didefinisikan dalam [RFC2256] adalah
wajib.
2.3. kelas objek
Kelas-kelas objek berikut didefinisikan dalam dokumen ini:
posixAccount
shadowAccount
posixGroup
ipService
ipProtocol
oncRpc
IPHost
ipNetwork
nisNetgroup
nisMap
nisObject
ieee802Device
bootableDevice
Selain itu, beberapa kelas didefinisikan dalam [RFC2256] diperlukan.
Howard Eksperimental [Page 4]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
2.4. definisi sintaks
Berikut ini definisi sintaks [RFC2252] digunakan oleh skema ini.
The nisNetgroupTripleSyntax mewakili NIS Netgroup tiga kali lipat:
(NisSchema.0.0 NAMA 'nisNetgroupTripleSyntax'
DESC 'NIS Netgroup tiga')
Nilai dalam sintaks ini diwakili oleh berikut ini:
nisnetgrouptriple = "(" hostname "," username "," domainname ")"
hostname = "" / "-" / keystring
username = "" / "-" / keystring
domainname = "" / "-" / keystring
server X.500 dapat menggunakan representasi berikut di atas
sintaksis:
nisNetgroupTripleSyntax :: = URUTAN {
hostname [0] IA5String OPTIONAL,
nama pengguna [1] IA5String OPTIONAL,
domainname [2] IA5String OPTIONAL
}
Sintaks bootParameterSyntax merupakan parameter boot:
(NisSchema.0.1 NAMA 'bootParameterSyntax'
DESC 'parameter Boot')
dimana:
bootparameter = kunci "=" server ":" path
key = keystring
server = keystring
path = keystring
server X.500 dapat menggunakan representasi berikut di atas
sintaksis:
bootParameterSyntax :: = URUTAN {
kunci IA5String,
Server IA5String,
jalan IA5String
}
Nilai mengikuti sintaks ini dikodekan sebagai string dengan LDAP
server.
Howard Eksperimental [Page 5]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
3. Definisi Atribut
Bagian ini berisi definisi atribut yang harus dilaksanakan oleh Duas
mendukung skema ini.
(NisSchema.1.0 NAMA 'uidNumber'
DESC 'Sebuah bilangan bulat unik mengidentifikasi pengguna dalam
domain administrasi '
KESETARAAN integerMatch SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.1 NAMA 'gidNumber'
DESC 'Sebuah bilangan bulat unik mengidentifikasi kelompok dalam
domain administrasi '
KESETARAAN integerMatch SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.2 NAMA 'gecos'
DESC 'The GECOS lapangan; nama umum '
KESETARAAN caseIgnoreIA5Match
substring caseIgnoreIA5SubstringsMatch
SYNTAX 'IA5String' TUNGGAL-VALUE)
(NisSchema.1.3 NAMA 'HomeDirectory'
DESC 'The path absolut ke direktori rumah'
KESETARAAN caseExactIA5Match
SYNTAX 'IA5String' TUNGGAL-VALUE)
(NisSchema.1.4 NAMA 'loginShell'
DESC 'Path ke shell login'
KESETARAAN caseExactIA5Match
SYNTAX 'IA5String' TUNGGAL-VALUE)
(NisSchema.1.5 NAMA 'shadowLastChange'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.6 NAMA 'shadowMin'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.7 NAMA 'shadowMax'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.8 NAMA 'shadowWarning'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.9 NAMA 'shadowInactive'
Howard Eksperimental [Page 6]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.10 NAMA 'shadowExpire'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.11 NAMA 'shadowFlag'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.12 NAMA 'memberUid'
KESETARAAN caseExactIA5Match
substring caseExactIA5SubstringsMatch
SYNTAX 'IA5String')
(NisSchema.1.13 NAMA 'memberNisNetgroup'
KESETARAAN caseExactIA5Match
substring caseExactIA5SubstringsMatch
SYNTAX 'IA5String')
(NisSchema.1.14 NAMA 'nisNetgroupTriple'
DESC 'NetGroup tiga'
SYNTAX 'nisNetgroupTripleSyntax')
(NisSchema.1.15 NAMA 'ipServicePort'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.16 NAMA 'ipServiceProtocol'
Nama SUP)
(NisSchema.1.17 NAMA 'ipProtocolNumber'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.18 NAMA 'oncRpcNumber'
KESETARAAN integerMatch
SYNTAX 'INTEGER' TUNGGAL-VALUE)
(NisSchema.1.19 NAMA 'ipHostNumber'
Alamat IP DESC 'sebagai desimal bertitik, misalnya. 192.168.1.1,
menghilangkan nol terkemuka '
KESETARAAN caseIgnoreIA5Match
SYNTAX 'IA5String {128}')
(NisSchema.1.20 NAMA 'ipNetworkNumber'
jaringan IP DESC 'sebagai desimal bertitik, misalnya. 192.168,
Howard Eksperimental [Page 7]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
menghilangkan nol terkemuka '
KESETARAAN caseIgnoreIA5Match
SYNTAX 'IA5String {128}' TUNGGAL-VALUE)
(NisSchema.1.21 NAMA 'ipNetmaskNumber'
DESC 'netmask IP sebagai desimal bertitik, misalnya. 255.255.255.0,
menghilangkan nol terkemuka '
KESETARAAN caseIgnoreIA5Match
SYNTAX 'IA5String {128}' TUNGGAL-VALUE)
(NisSchema.1.22 NAMA 'MAC address'
alamat DESC 'MAC di maksimal, usus dipisahkan hex
notasi, misalnya. 00: 00: 92: 90: ee: e2 '
KESETARAAN caseIgnoreIA5Match
SYNTAX 'IA5String {128}')
(NisSchema.1.23 NAMA 'bootParameter'
DESC 'parameter rpc.bootparamd'
SYNTAX 'bootParameterSyntax')
(NisSchema.1.24 NAMA 'bootfile'
DESC 'Boot nama image'
KESETARAAN caseExactIA5Match
SYNTAX 'IA5String')
(NisSchema.1.26 NAMA 'nisMapName'
Nama SUP)
(NisSchema.1.27 NAMA 'nisMapEntry'
KESETARAAN caseExactIA5Match
substring caseExactIA5SubstringsMatch
SYNTAX 'IA5String {1024}' TUNGGAL-VALUE)
4. definisi Kelas
Bagian ini berisi definisi kelas yang akan dilaksanakan oleh Duas
mendukung skema.
Kelas rfc822MailGroup objek MUNGKIN digunakan untuk mewakili mail
kelompok untuk tujuan ekspansi alias. Beberapa skema alternatif
untuk routing dan pengiriman email menggunakan direktori LDAP, yang
di luar lingkup dokumen ini.
(SUP atas TAMBAHAN nisSchema.2.0 NAMA 'posixAccount'
DESC 'Abstraksi dari rekening dengan POSIX atribut'
HARUS (cn $ uid $ uidNumber $ gidNumber $ HomeDirectory)
MAY (userPassword $ loginShell $ gecos $ deskripsi))
Howard Eksperimental [Page 8]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
(SUP atas TAMBAHAN nisSchema.2.1 NAMA 'shadowAccount'
DESC 'atribut tambahan untuk shadow password'
HARUS uid
MAY (userPassword $ shadowLastChange $ shadowMin
shadowMax $ shadowWarning $ shadowInactive $
shadowExpire $ shadowFlag $ deskripsi))
(NisSchema.2.2 NAMA 'posixGroup' SUP atas STRUKTURAL
DESC 'Abstraksi dari kelompok rekening'
HARUS (cn $ gidNumber)
MAY (userPassword $ memberUid $ deskripsi))
(NisSchema.2.3 NAMA 'ipService' SUP atas STRUKTURAL
DESC 'Abstraksi layanan Internet Protocol.
Peta port IP dan protokol (seperti tcp atau udp)
untuk satu atau lebih nama; nilai dibedakan dari
atribut cn menunjukkan kanonik layanan ini
nama'
HARUS (cn $ ipServicePort $ ipServiceProtocol)
MEI (deskripsi))
(NisSchema.2.4 NAMA 'ipProtocol' SUP atas STRUKTURAL
DESC 'Abstraksi dari protokol IP. Memetakan sebuah nomor protokol
untuk satu atau lebih nama. Nilai dibedakan dari cn
atribut menunjukkan nama kanonik protokol ini '
HARUS (cn $ ipProtocolNumber $ deskripsi)
MAY deskripsi)
(NisSchema.2.5 NAMA 'oncRpc' SUP atas STRUKTURAL
DESC 'Abstraksi dari Open Network Computing (ONC)
[RFC1057] Remote Procedure Call (RPC) yang mengikat.
Kelas ini memetakan jumlah RPC ONC untuk nama.
Nilai dibedakan dari cn atribut Menandakan
layanan RPC ini nama kanonik '
HARUS (cn $ oncRpcNumber $ deskripsi)
MAY deskripsi)
(SUP atas TAMBAHAN nisSchema.2.6 NAMA 'IPHost'
DESC 'Abstraksi dari sebuah host, perangkat IP. dibedakan
nilai atribut cn menunjukkan kanonik host
nama. Perangkat HARUS digunakan sebagai kelas struktural '
HARUS (cn $ ipHostNumber)
MAY (l $ deskripsi $ manager))
(NisSchema.2.7 NAMA 'ipNetwork' SUP atas STRUKTURAL
DESC 'Abstraksi jaringan. Nilai dibedakan dari
atribut cn menunjukkan nama kanonik jaringan '
Howard Eksperimental [Page 9]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
HARUS (cn $ ipNetworkNumber)
MAY (ipNetmaskNumber $ l $ deskripsi $ manager))
(NisSchema.2.8 NAMA 'nisNetgroup' SUP atas STRUKTURAL
DESC 'Abstraksi dari Netgroup a. Bisa merujuk ke Netgroups lain
HARUS cn
MAY (nisNetgroupTriple $ memberNisNetgroup $ deskripsi))
(NisSchema.2.09 NAMA 'nisMap' SUP atas STRUKTURAL
DESC 'A abstraksi generik dari peta NIS'
HARUS nisMapName
MAY deskripsi)
(NisSchema.2.10 NAMA 'nisObject' SUP atas STRUKTURAL
DESC 'Entri dalam peta NIS'
HARUS (cn $ nisMapEntry $ nisMapName)
MAY deskripsi)
(SUP atas TAMBAHAN nisSchema.2.11 NAMA 'ieee802Device'
DESC 'Perangkat dengan alamat MAC; perangkat HARUS
digunakan sebagai kelas struktural '
MAY MAC address)
(SUP atas TAMBAHAN nisSchema.2.12 NAMA 'bootableDevice'
DESC 'Perangkat dengan parameter boot; perangkat HARUS
digunakan sebagai kelas struktural '
MAY (bootfile $ bootParameter))
5. Pelaksanaan rincian
5.1. metode resolusi yang disarankan
cara yang disukai mengarahkan aplikasi client (satu menggunakan
layanan bersama perpustakaan C) menggunakan LDAP sebagai informasinya
sumber untuk fungsi yang tercantum dalam 5.2 adalah untuk memodifikasi kode sumber
untuk langsung permintaan LDAP. Sebagai sumber untuk C perpustakaan komersial dan
aplikasi jarang tersedia untuk pengguna akhir, orang bisa meniru
didukung nameservice (seperti NIS). (Ini juga merupakan yang sesuai
kesempatan untuk melakukan caching entri di alamat proses
spasi.) Dalam kasus NIS, implementasi referensi yang luas
tersedia dan antarmuka RPC terkenal.
Sarana yang sistem operasi diarahkan untuk menggunakan LDAP adalah
tergantung implementasi. Sebagai contoh, beberapa sistem operasi dan C
perpustakaan mendukung pengguna akhir resolvers extensible menggunakan dinamis
perpustakaan loadable dan nameservice "switch". Cara di mana
DUA menempatkan server LDAP juga tergantung implementasi.
Howard Eksperimental [Page 10]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
5.2. fungsi perpustakaan terpengaruh
Fungsi-fungsi berikut biasanya ditemukan di perpustakaan C dari
kebanyakan UNIX dan POSIX sistem compliant. Filter pencarian LDAP
[RFC2254] yang dapat digunakan untuk memenuhi panggilan fungsi disertakan
di samping setiap nama fungsi. Parameter yang dilambangkan oleh% s dan% d untuk
tali dan integer argumen masing-masing. Antrean panjang yang rusak.
getpwnam () (& (objectClass = posixAccount) (uid =% s))
getpwuid () (& (objectClass = posixAccount)
(UidNumber =% d))
getpwent () (objectClass = posixAccount)
getspnam () (& (objectClass = shadowAccount) (uid =% s))
getspent () (objectClass = shadowAccount)
getgrnam () (& (objectClass = posixGroup) (cn =% s))
getgrgid () (& (objectClass = posixGroup)
(GidNumber =% d))
getgrent () (objectClass = posixGroup)
getservbyname () (& (objectClass = ipService)
(Cn =% s) (ipServiceProtocol =% s))
getservbyport () (& (objectClass = ipService)
(IpServicePort =% d)
(IpServiceProtocol =% s))
getservent () (objectClass = ipService)
getrpcbyname () (& (objectClass = oncRpc) (cn =% s))
getrpcbynumber () (& (objectClass = oncRpc) (oncRpcNumber =% d))
getrpcent () (objectClass = oncRpc)
getprotobyname () (& (objectClass = ipProtocol) (cn =% s))
getprotobynumber () (& (objectClass = ipProtocol)
(IpProtocolNumber =% d))
getprotoent () (objectClass = ipProtocol)
gethostbyname () (& (objectClass = IPHost) (cn =% s))
gethostbyaddr () (& (objectClass = IPHost) (ipHostNumber =% s))
gethostent () (objectClass = IPHost)
getnetbyname () (& (objectClass = ipNetwork) (cn =% s))
getnetbyaddr () (& (objectClass = ipNetwork)
(IpNetworkNumber =% s))
getnetent () (objectClass = ipNetwork)
setnetgrent () (& (objectClass = nisNetgroup) (cn =% s))
Howard Eksperimental [Page 11]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
5.3. Menafsirkan pengguna dan kelompok entri
Pengguna dan kelompok resolusi diprakarsai oleh fungsi diawali oleh
getpw dan getgr masing-masing. Atribut uid berisi pengguna
nama login. Atribut cn, di entri posixGroup, berisi
nama kelompok.
Kelas objek akun menyediakan kelas struktural nyaman untuk
posixAccount, dan HARUS digunakan di mana atribut tambahan tidak
wajib.
Disarankan uid itu dan cn digunakan sebagai RDN atribut jenis
untuk posixAccount dan posixGroup entri, masing-masing.
bidang GECOS akun ini sebaiknya ditentukan oleh nilai
gecos atribut. Jika tidak ada gecos atribut ada, nilai cn
Atribut HARUS digunakan. (Keberadaan atribut gecos memungkinkan
informasi tertanam dalam GECOS bidang, seperti telepon pengguna
nomor, harus dikembalikan ke klien tanpa overloading cn
atribut. Hal ini juga mengakomodasi direktori dimana nama umum
tidak mengandung nama lengkap pengguna.)
Entri dari posixAccount kelas, posixGroup, atau shadowAccount tanpa
atribut userPassword TIDAK HARUS digunakan untuk otentikasi. Itu
client harus dikembalikan password non-matchable seperti "x".
nilai userPassword HARUS diwakili oleh sintaks berikut:
passwordvalue = schemeprefix encryptedpassword
schemeprefix = "{" skema "}"
Skema = "crypt" / "md5" / "sha" / altscheme
altscheme = "x-" keystring
encryptedpassword = terenkripsi sandi
password terenkripsi berisi sebuah kunci plaintext hash menggunakan
Skema algoritma.
nilai userPassword yang tidak mematuhi sintaks ini TIDAK HARUS
digunakan untuk otentikasi. The DUA HARUS iterate melalui nilai-nilai
atribut sampai nilai yang cocok dengan sintaks di atas ditemukan. Hanya
jika encryptedpassword adalah string kosong tidak pengguna tidak memiliki
kata sandi. Duas tidak diharuskan untuk mempertimbangkan skema enkripsi yang
klien tidak akan mengenali; dalam banyak kasus, itu mungkin cukup untuk
mempertimbangkan hanya "crypt".
Berikut ini adalah contoh dari atribut userPassword:
userPassword: {crypt} X5 / DBrWPOQQaI
Howard Eksperimental [Page 12]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
Sebuah standar masa depan dapat menentukan deskripsi atribut LDAP v3 untuk
mewakili userPasswords hash, seperti tercantum di bawah. Skema ini HARUS TIDAK
digunakan dengan Duas LDAP v2 dan DSA.
attributetype = AttributeName attributeoption September
AttributeName = "userPassword"
September = ";"
attributeoption = schemeclass "-" skema
schemeclass = "hash" / altschemeclass
Skema = "crypt" / "md5" / "sha" / altscheme
altschemeclass = "x-" keystring
altscheme = keystring
Berikut ini adalah contoh dari atribut userPassword, diwakili dengan
LDAP deskripsi atribut v3:
userPassword; hash-crypt: X5 / DBrWPOQQaI
Sebuah DUA MUNGKIN memanfaatkan atribut di kelas shadowAccount untuk
menyediakan layanan shadow password (getspnam () dan getspent ()). Sedemikian
kasus, DUA TIDAK HARUS menggunakan atribut userPassword untuk
getpwnam () et al, dan harus kembali password non-matchable (seperti
"X") kepada klien sebagai gantinya.
5.4. Menafsirkan host dan jaringan
The ipHostNumber dan ipNetworkNumber atribut didefinisikan dalam
preferensi untuk DNSRECORD (didefinisikan dalam [RFC1279]), dalam rangka untuk menyederhanakan
peran DUA dalam menafsirkan entri dalam direktori. Sebuah DNSRECORD
mengungkapkan catatan sumber daya lengkap, termasuk waktu untuk hidup dan
Data kelas, yang asing untuk skema ini.
Selain itu, kelas IPHost dan ipNetwork mengizinkan host atau
jaringan (masing-masing) dan semua alias untuk diwakili oleh
single entry dalam direktori. Hal ini tidak selalu mungkin jika
catatan sumber daya DNS dipetakan langsung ke entri LDAP.
Implementasi yang ingin menggunakan LDAP untuk menguasai informasi zona DNS
tidak dilarang melakukannya, dan hanya dapat menghindari IPHost dan
kelas ipNetwork.
Dokumen ini mengubah, meskipun tidak secara eksklusif, yang ipNetwork
kelas didefinisikan dalam [RFC1279], dalam rangka mencapai penamaan yang konsisten
dengan IPHost. Atribut ipNetworkNumber juga digunakan dalam
kelas objek siteContact [ROSE].
Howard Eksperimental [Page 13]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
Nol tertinggal dalam alamat jaringan harus dihilangkan. CIDR-style
alamat jaringan (misalnya. 192.168.1 / 24) MUNGKIN digunakan.
Host dengan alamat IPv6 HARUS ditulis dalam mereka bentuk "disukai"
sebagaimana didefinisikan dalam bagian 2.2.1 dari [RFC1884], sehingga semua komponen
alamat ditunjukkan dan nol terkemuka dihilangkan. Ini
menyediakan sarana konsisten menyelesaikan ipHosts berdasarkan alamat.
5.5. Menafsirkan entitas lain
Secara umum, pemetaan satu-ke-satu antara entitas dan entri LDAP adalah
mengusulkan, bahwa setiap entitas memiliki tepat satu representasi dalam
DIT. Dalam beberapa kasus ini tidak layak; misalnya, layanan yang
diwakili di lebih dari satu domain protokol. Pertimbangkan
entri berikut:
dn: cn = domain, dc = aja, dc = com
cn: domain
cn: nameserver
objectClass: top
objectClass: ipService
ipServicePort: 53
ipServiceProtocol: tcp
ipServiceProtocol: udp
Catatan ini harus memetakan ke dua (2) entitas layanan berikut:
domain 53 / tcp nameserver
domain 53 / udp nameserver
Sementara di atas dua entitas dapat direpresentasikan sebagai LDAP terpisah
entitas, dengan nama dibedakan berbeda (seperti
cn = domain + ipServiceProtocol = tcp, ... dan
cn = domain + ipServiceProtocol = udp, ...) akan lebih mudah untuk mewakili
mereka sebagai satu entri. (Jika layanan diwakili dalam beberapa
domain protokol dengan port yang berbeda, maka beberapa entri yang
wajib; RDNS multivalued dapat digunakan untuk membedakan mereka.)
Dengan pengecualian dari nilai-nilai userPassword, yang diurai menurut
untuk sintaks dipertimbangkan dalam bagian 5.2, nilai-nilai kosong (yang terdiri
dari nol panjang string) dikembalikan oleh DUA kepada klien. Itu
DUA HARUS menolak setiap entri yang tidak sesuai dengan skema
(Hilang atribut wajib). entri yang tidak sesuai HARUS
diabaikan sementara pencacahan entri.
Kelas objek nisObject MUNGKIN digunakan sebagai alat generik
mewakili entitas NIS. Penggunaannya tidak dianjurkan; di mana dukungan
untuk entitas yang tidak dijelaskan dalam skema ini diinginkan, yang sesuai
Howard Eksperimental [Page 14]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
skema harus dibuat. Pelaksana sangat disarankan untuk
dukungan pengguna akhir pemetaan extensible antara entitas NIS dan objek
kelas. (Dimana kelas nisObject digunakan, atribut nisMapName
dapat digunakan sebagai RDN.)
5.6. Canonicalizing entri dengan atribut multi-nilai penamaan
Untuk entitas seperti host, layanan, jaringan, protokol, dan RPC,
mana mungkin ada satu atau lebih alias, masing-masing entri
nama dibedakan relatif HARUS digunakan untuk menentukan kanonik yang
nama. Apa nilai-nilai lain untuk atribut yang sama digunakan sebagai alias.
Misalnya, layanan yang dijelaskan dalam bagian 5.5 memiliki kanonik yang
nama "domain" dan tepat satu alias, "nameserver".
Skema dalam dokumen ini umumnya hanya mendefinisikan satu atribut per
kelas yang cocok untuk membedakan suatu entitas (tidak termasuk
atribut dengan sintaks integer; diasumsikan bahwa entri akan
dibedakan atas nama). Biasanya, ini adalah nama umum (cn)
atribut. Ini membantu DUA dalam menentukan nama kanonik dari
entitas, karena dapat memeriksa nilai relatif dibedakan
nama. Alias demikian nilai-nilai dari atribut yang membedakan
(Seperti cn) yang tidak sesuai dengan nama kanonik entitas.
Dalam hal atribut yang berbeda digunakan untuk membedakan
entri, yang mungkin menjadi kasus di mana kelas objek ini digunakan sebagai
kelas tambahan, nama kanonik entri ini mungkin tidak hadir dalam
yang RDN. Dalam hal ini, DUA HARUS memilih salah satu dari non
nilai-nilai dibedakan untuk mewakili nama kanonik entitas. sebagai
server direktori menjamin tidak ada pemesanan nilai atribut, hal itu mungkin
tidak mungkin untuk membedakan entri deterministik. Ini
ambiguitas TIDAK BOLEH diselesaikan dengan pemetaan satu entri direktori ke
beberapa entitas.
6. Pelaksanaan fokus
Sebuah server NIS yang menggunakan LDAP bukan file lokal telah
dikembangkan yang mendukung skema didefinisikan dalam dokumen ini.
Sebuah acuan pelaksanaan kode C resolusi perpustakaan telah
ditulis untuk Free Software Foundation. Ini mungkin mendukung lainnya C
perpustakaan yang mendukung Nama Service Switch (NSS) atau
Information Retrieval Service (IRS).
Penulis telah tersedia satu set didistribusikan secara gratis script
yang mem-parsing database lokal seperti / etc / passwd dan / etc / hosts ke
bentuk yang sesuai untuk loading ke server LDAP.
Howard Eksperimental [Page 15]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
7. Pertimbangan Keamanan
Keseluruhan pertimbangan keamanan terkait berada di luar ruang lingkup
dokumen ini. Perlu dicatat bahwa membuat password terenkripsi dengan
dipahami secara luas fungsi hash (seperti crypt ()) yang tersedia untuk non-
pengguna istimewa berbahaya karena menghadapkan mereka ke kamus
dan serangan brute-force. Ini diusulkan hanya untuk kompatibilitas
dengan implementasi sistem UNIX yang ada. Tempat di mana keamanan
penting HARUS mempertimbangkan untuk menggunakan layanan otentikasi yang kuat untuk
otentikasi pengguna.
Atau, password terenkripsi dapat dibuat tersedia hanya untuk
subset dari Duas istimewa, yang akan memberikan "bayangan" password
layanan untuk aplikasi client. Ini mungkin sulit untuk menegakkan.
Karena skema mewakili entitas sistem-tingkat operasi, akses
untuk entitas ini HARUS diberikan atas dasar kebijaksanaan. (Sana
gunanya membatasi akses ke data yang akan
ulang tanpa pembatasan, namun.) Hal ini terutama
penting bahwa hanya administrator dapat memodifikasi entri didefinisikan dalam ini
skema, dengan pengecualian memungkinkan pokok untuk mengubah mereka
password (yang mungkin dilakukan atas nama pengguna dengan klien terikat
sebagai kepala unggul, sehingga pembatasan sandi mungkin
ditegakkan). Misalnya, jika pengguna diizinkan untuk mengubah nilai
atribut uidNumber mereka, mereka bisa menumbangkan keamanan dengan
equivalencing akun mereka dengan akun superuser.
Sebuah subtree dari DIT yang yang akan dipublikasikan ulang oleh DUA (seperti
NIS gateway) HARUS berada dalam domain administrasi yang sama bahwa
republishing DUA mewakili. (Misalnya, kepala sekolah di luar sebuah
organisasi, sementara dibayangkan bagian dari DIT itu, tidak harus
dipertimbangkan dengan tingkat yang sama dari otoritas sebagai orang-orang dalam
organisasi.)
Akhirnya, perawatan harus dilakukan dengan atribut bilangan bulat dari
sifat sensitif (terutama uidNumber dan gidNumber
atribut) yang mengandung nilai-nilai nol-panjang. Duas MUNGKIN mengobati seperti
nilai-nilai sebagai sesuai dengan "tidak ada" atau pengguna "nogroup" dan kelompok,
masing-masing.
8. Ucapan Terima Kasih
Berkat Leif Hedstrom dari Netscape Communications Corporation,
Michael Grant dan Rosanna Lee Sun Microsystems Inc., Ed Reed dari
Novell Inc., dan Mark Wahl Kritis Angle Inc untuk mereka yang berharga
kontribusi untuk pengembangan skema ini. Berkat Andrew
Josey dari The Open Group untuk mengklarifikasi penggunaan merek dagang UNIX,
dan Tim Howes dan Peter J. Cherny atas dukungan mereka.
Howard Eksperimental [Page 16]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
UNIX adalah merek dagang terdaftar dari The Open Group.
9. Referensi
[RFC1057]
Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protokol
Keterangan Versi 2 ", RFC 1057, Juni 1988.
[RFC1279]
Kille, S., "X.500 dan Domain", RFC 1279, November 1991.
[RFC1884]
Hinden, R., dan S. Deering, "IP Versi 6 Addressing
Arsitektur ", RFC 1884, Desember 1995.
[RFC2119]
Bradner, S., "Kata Kunci untuk digunakan dalam RFC untuk Tunjukkan Kebutuhan
Tingkat ", BCP 14, RFC 2119, Maret 1997.
[RFC2251]
Wahl, M., Howes, T., dan S. Kille, "Lightweight Directory Access
Protocol (v3) ", RFC 2251, Desember 1997.
[RFC2252]
Wahl, M., Coulbeck, A., Howes, T., dan S. Kille, "Ringan
Directory Access Protocol (v3): Atribut Sintaks Definisi ",
RFC 2252, Desember 1997.
[RFC2254]
Howes, T., "The String Representasi LDAP Cari Filter",
RFC 2254, Desember 1997.
[RFC2256]
Wahl, M., "Ringkasan dari X.500 (96) Skema Pengguna untuk digunakan dengan
LDAPv3 ", RFC 2256, Desember 1997.
[MAWAR]
M. T. Rose, "The Little Black Book: Mail Bonding dengan OSI
Directory Services ", ISBN 0-13-683210-5, Prentice-Hall, Inc.,
1992.
[X500]
"Informasi Pengolahan Sistem - Open System Interconnection -
Direktori: Sekilas Konsep, Model dan layanan ",
ISO / IEC JTC 1 / SC21, Standar Internasional 9594-1, 1988.
Howard Eksperimental [Page 17]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
[XOPEN]
ISO / IEC 9945-1: 1990, Teknologi Informasi - Operasi Portabel
Sistem Interface (POSIX) - Bagian 1: Aplikasi Sistem
Programming Interface (API) [C Bahasa]
10. Penulis Alamat
Luke Howard
PO Box 59
Central Park Vic 3145
Australia
EMail: lukeh@xedoc.com
Howard Eksperimental [Page 18]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
entri A. Contoh
Contoh yang dijelaskan dalam bagian ini diberikan untuk menggambarkan
skema yang dijelaskan dalam memo ini. Mereka tidak dimaksudkan untuk menjadi lengkap.
Entri berikut adalah contoh dari kelas posixAccount:
dn: uid = lester, dc = aja, dc = com
objectClass: top
objectClass: akun
objectClass: posixAccount
uid: lester
cn: Lester yang kupu-kupu malam
userPassword: {crypt} X5 / DBrWPOQQaI
gecos: Lester
loginShell: / bin / csh
uidNumber: 10
gidNumber: 10
HomeDirectory: / home / lester
Hal ini terkait masuknya UNIX file password sistem:
lester: X5 / DBrWPOQQaI: 10: 10: Lester: / home / lester: / bin / sh
Entri berikut adalah contoh dari kelas IPHost:
dn: cn = peg.aja.com, dc = aja, dc = com
objectClass: top
objectClass: perangkat
objectClass: IPHost
objectClass: bootableDevice
objectClass: ieee802Device
cn: peg.aja.com
cn: www.aja.com
ipHostNumber: 10.0.0.1
MAC address: 00: 00: 92: 90: ee: e2
bootfile: mach
bootParameter: = root fs: / nfsroot / peg
bootParameter: swap = fs: / nfsswap / peg
bootParameter: membuang = fs: / nfsdump / peg
Catatan ini merupakan tuan rumah kanonis peg.aja.com, juga dikenal sebagai
www.aja.com. Alamat Ethernet dan empat parameter boot juga
ditentukan.
Howard Eksperimental [Page 19]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
Contoh dari kelas nisNetgroup:
dn: cn = kupu-kupu malam, dc = aja, dc = com
objectClass: top
objectClass: nisNetgroup
cn: kupu-kupu malam
nisNetgroupTriple: (charlemagne, pasak, dunes.aja.com)
nisNetgroupTriple: (lester, -,)
memberNisNetgroup: kamakiriad
Catatan ini merupakan kupu-kupu malam Netgroup, yang berisi dua
Triple (pengguna charlemagne, pasak tuan rumah, dan domain
dunes.aja.com; dan, pengguna lester, tidak ada tuan rumah, dan setiap domain) dan satu
Netgroup (kamakiriad).
Akhirnya, contoh kelas nisObject:
dn: nisMapName = trek, dc = bukit pasir, dc = aja, dc = com
objectClass: top
objectClass: nisMap
nisMapName: trek
dn: cn = Maxine, nisMapName = trek, dc = bukit pasir, dc = aja, dc = com
objectClass: top
objectClass: nisObject
cn: Maxine
nisMapName: trek
nisMapEntry: kupu-kupu malam $ 4
Catatan ini merupakan trek peta NIS, dan entri peta tunggal.
Howard Eksperimental [Page 20]
RFC 2307 Menggunakan LDAP sebagai Jaringan Informasi Layanan Maret 1998
Pernyataan Copyright penuh
Copyright (C) The Internet Society (1998). Seluruh hak cipta.
dokumen dan terjemahan itu ini dapat disalin dan diserahkan kepada
orang lain, dan karya turunan yang mengomentari atau menjelaskannya
atau membantu dalam pelaksanaannya dapat dibuat, disalin, diterbitkan
dan didistribusikan, secara keseluruhan atau sebagian, tanpa pembatasan apapun
baik, asalkan pemberitahuan hak cipta di atas dan ayat ini
disertakan pada semua salinan tersebut dan karya turunan. Namun, ini
Dokumen itu sendiri tidak dapat diubah dengan cara apapun, misalnya dengan menghapus
hak cipta pemberitahuan atau referensi ke Internet Society atau lainnya
organisasi internet, kecuali yang diperlukan untuk tujuan
mengembangkan standar Internet dalam hal prosedur
hak cipta didefinisikan dalam proses Standar Internet harus
diikuti, atau seperti yang diperlukan untuk menerjemahkannya ke dalam bahasa lain selain
Inggris.
Izin terbatas diberikan di atas adalah abadi dan tidak akan
dicabut oleh Internet Society atau penerus atau wakilnya.
Dokumen ini dan informasi yang terkandung di sini disediakan pada
"AS IS" dasar dan THE INTERNET MASYARAKAT DAN INTERNET ENGINEERING
TASK FORCE MENOLAK SEMUA JAMINAN, TERSURAT ATAU TERSIRAT, TERMASUK
NAMUN TIDAK TERBATAS PADA JAMINAN BAHWA PENGGUNAAN INFORMASI
SINI TIDAK AKAN MELANGGAR HAK ATAU JAMINAN TERSIRAT
KELAYAKAN UNTUK TUJUAN TERTENTU.
Howard Eksperimental [Page 21]
Google Terjemahan untuk Bisnis:Perangkat Penerjemah
Penerjemah Situs WebPeluang Pasar Global
0 komentar:
Posting Komentar