| Yazar | W. Crowther, E. Harslem, J. Heafner | | Kurum | UCLA | | Tarih | 15 November 1971 | | Durum | Network Working Group Yorum Talebi | | RFC Numarası | 264 |
Bu makale RFC 171, NIC 6793’ün gözden geçirilmiş bir sürümüdür. RFC 171’de yapılan değişiklikler aşağıda verilmiştir. Ardından protokol, kullanım kolaylığı için yeniden ifade edilmiştir.
RFC 171’DEKİ DEĞİŞİKLİKLER
- Hata (Type B5) işlemlerindeki sıra numarası alanı 16 bite değiştirilmiştir; böylece önceki tanımdaki belirsizlik giderilmiştir. Ayrıca, bilgi ayırıcıları (Type B4) işlemleri de 16 bitlik bir sıra numarası alanı içerecektir.
- Mevcut modlar (Type B3) işlemleri, artık hem alma hem de gönderme yerine yalnızca alma için mevcut modları tanımlayacaktır. Simplex bağlantılarda mod mevcut işlemleri gönderilmemelidir çünkü anlamlı değildir. Full-duplex bağlantılarda ise mod mevcut işlemleri hâlâ gereklidir.
- Bilgi ayırıcılarındaki "End Code" ve abort işlemlerindeki "function" için kod atamaları, "bit-coding" yerine sayısal bir sırayı yansıtacak şekilde değiştirilmiştir.
- Küçük editoryal değişiklikler.
I. GİRİŞ
Uzak iş girişi, dosya aktarımı, ağ posta sistemi, grafikler, uzaktan program yürütme ve blok veri terminalleriyle iletişim (özellikle terminal IMP'leri bağlamında yazıcılar, kart, kağıt şerit ve manyetik bant ekipmanları gibi) gibi çok çeşitli uygulamalarda veri aktarımı için ortak bir protokol arzu edilir. Yukarıdaki uygulamaların bazılarını ya da tamamını kapsayan kapsamlı bir dosya aktarım protokolü geliştirmek mümkün olsa da, veri aktarımı ile uygulama işlevlerinin ayrılması uygulama gerçekleştirimlerinde esneklik sağlayabilir ve karmaşıklığı azaltabilir. Veri aktarım işlevinin belirli uygulama işlevlerinden ayrılması ayrıca program ve protokollerin çoğalmasını da azaltabilir.
Bu nedenle, dosya aktarımı, uzak iş girişi ve diğer uygulama protokollerinde veri aktarımı için kullanılması gereken bir veri aktarım protokolü (DTP) tanımladık. Bu makale yalnızca veri aktarım protokolü ile ilgilenmektedir. Eşlik eden bir makale (RFC 265) dosya aktarım protokolünü açıklamaktadır.
II. TARTIŞMA
Veri aktarım protokolü (DTP) üç temel işlev yerine getirir. NCP mesajlarının "mantıksal" bloklara (işlemler, birimler, kayıtlar, gruplar ve dosyalar) uygun biçimde ayrılmasını sağlar, veri ile kontrol bilgisinin ayrılmasına olanak tanır ve bazı hata kontrol mekanizmaları içerir.
Aktarım Modları
DTP, mesajların işlemlere ayrılması için üç moda izin verir [1]. Birincisi, yalnızca bağlantı kapatıldığında sonlanan belirsiz uzunlukta bir bit akışıdır (yani bit akışı bağlantı süresi boyunca tek bir işlemi temsil eder). Bu mod, hostlar ile terminal IMP'leri (TIP'ler) arasındaki veri aktarımında yararlı olabilir.
İkinci mod, ASCII DLE (Data Link Escape) kuralına benzer "şeffaf" blok kuralını kullanır. "Şeffaf" modda işlemler (keyfi uzunlukta olabilir) DLE ETX karakter dizisiyle karşılaşıldığında sona erer (DLE ve ETX 8 bitlik karakter kodlarıdır). Veri akışı içinde DLE ETX dizisinin oluşma olasılığını önlemek için, iletim sırasında her DLE ortaya çıkışı DLE DLE ile değiştirilir. Ek DLE alım sırasında çıkarılır. ASCII kuralından bir fark, "şeffaf" bloğun DLE STX ile değil, bir işlem türü baytıyla başlamasıdır. Bu mod, terminal IMP'leri arasındaki veri aktarımında yararlı olabilir.
Üçüncü mod bir sayım mekanizması kullanır. Her işlem, bilgi bitleri ve dolgu (yani bilgi olmayan) bitleri için ayrı ikili sayımlar içeren sabit uzunlukta bir tanımlayıcı alan ile başlar. Eğer bir işlemde dolgu biti yoksa, dolgu sayısı sıfırdır. Bu mod çoğu hosttan hosta veri aktarımı uygulamasında yararlı olabilir.
DTP, aynı bağlantı üzerinde aktarım modlarının karışık biçimde kullanılmasına izin verir (yani aktarım modu bağlantı ile değil yalnızca işlem ile ilişkilidir). Aktarım modları hem veri hem de kontrol bilgisinin aktarımını temsil edebilir. Protokol, veri ve kontrol bilgisini daha alt bir seviyede ayırmak için veri ve kontrol işlemleri için farklı "type" kodları (SPECIFICATIONS bölümüne bakınız) sağlar. Bu özellik bazı gerçekleştirimleri basitleştirebilir.
Aktarım modlarının bir alt kümesinin uygulanması DTP tarafından açıkça izin verilen bir durumdur. Farklı aktarım modu alt kümeleri kullanan hostlar arasında uyumluluk sağlamak için başlangıçta bir "handshake" prosedürü kullanılabilir. Bu handshake, alma için mevcut modlar hakkında bilgi alışverişini içerir. Böylece host programları bir bağlantı için kabul edilebilir aktarım modları üzerinde anlaşabilir.
DTP’nin Kullanımı
DTP’nin nasıl kullanılacağı büyük ölçüde uygulama protokolüne bağlıdır. Aktarım modlarının kullanımı ile DTP içinde sağlanan bilgi ayırıcı ve abort işlevlerinin kullanımı uygulama protokolü tarafından tanımlanır (SPECIFICATIONS bölümüne bakınız). Örneğin, bir uzak iş girişi protokolünde abort işlemleri bir işin yürütülmesini durdurmak için kullanılabilirken, başka bir uygulama protokolünde herhangi bir eyleme neden olmayabilir.
Ayrıca DTP’nin bir veri aktarım hizmeti tanımlamadığı da belirtilmelidir. DTP için tanımlanmış standart bir sunucu soketi veya başlangıç bağlantı protokolü yoktur. DTP’nin tanımladığı şey, blok veri aktarımı, dosya aktarımı, uzak iş girişi, ağ postası ve diğer uygulamalar için hizmetler sağlamada kullanılabilecek bir veri aktarım mekanizmasıdır.
DTP’nin farklı sahalarda nasıl uygulanacağı konusunda herhangi bir kısıtlama yoktur. Örneğin DTP, dosya aktarımı gibi bir uygulama programının içine gömülü olabilir ya da birkaç uygulama programı tarafından kullanılan ayrı bir hizmet programı veya alt yordam olabilir. Başka bir gerçekleştirim, DTP’de belirtilen işlevleri yerine getirmek için makrolar veya UUO'lar (PDP-10'larda uygulanmamış kullanıcı işlemleri) kullanabilir. Uygulamada DTP ile uygulama protokolleri arasındaki ayrımın yalnızca kavramsal düzeyde olması da mümkündür.
III. TEKNİK ÖZELLİKLER
1. Ağ Bağlantısı için Bayt Boyutu
DTP kullanan ağ bağlantıları için standart bayt boyutu 8 bittir. Bununla birlikte, uygulama protokolleri tarafından belirtilen diğer bayt boyutlarına da DTP tarafından izin verilir. Bu belgenin amacı açısından aksi belirtilmedikçe baytların 8 bit olduğu varsayılır.
2. İşlemler
DTP seviyesinde, bir bağlantı üzerinden iletilen tüm bilgiler bir işlem dizisidir. DTP, işlemlerin sınırlarını belirleme kurallarını tanımlar.
2A. Türler
Her işlemin ilk 8 bitlik baytı aşağıda gösterildiği gibi bir işlem türünü tanımlar. (Kod atamalarının TELNET protokolündeki atamalarla çakışmadığına dikkat edilmelidir.) İşlem türleri kendilerine atanmış onaltılık kod ile anılacaktır. (İşlem türleri Bölüm 2B’de daha ayrıntılı biçimde ele alınmaktadır.)
| Hex | Octal | İşlem Türü |
|---|---|---|
| B0 | 260 | Belirsiz bit akışı — veri |
| B1 | 261 | Şeffaf (DLE) blok — veri |
| B2 | 262 | Tanımlayıcı ve sayımlar — veri |
| B3 | 263 | Mevcut modlar (handshake) |
| B4 | 264 | Bilgi ayırıcıları |
| B5 | 265 | Hata kodları |
| B6 | 266 | Abort |
| B7 | 267 | İşlem yok (NoOp) |
| B8 | 270 | Belirsiz bit akışı — kontrol |
| B9 | 271 | Şeffaf (DLE) blok — kontrol |
| BA | 272 | Tanımlayıcı ve sayımlar — kontrol |
| BB–BF | 273–277 | Atanmamış ancak DTP için ayrılmış |
2B. Sözdizimi ve Anlam
2B.1 Type B0 ve B8 (belirsiz bit akışı modları)
Type B0 ve B8 işlemleri yalnızca NCP bağlantısı "kapatıldığında" sona erer. Bu seviyede DTP içinde başka bir kaçış kuralı tanımlanmamıştır. Bit akışı modunda bir bağlantının kapatılmasının örtük bir dosya ayırıcısı olduğunu (Bkz. Bölüm 2B.5) belirtmek gerekir.
2B.2 Type B1 ve B9 (şeffaf blok modları)
Type B1 ve B9 işlemleri DLE ETX bayt dizisiyle karşılaşıldığında sona erer. Gönderen, veri akışındaki her DLE oluşumunu DLE DLE dizisi ile değiştirmelidir. Alıcı ek DLE'yi kaldırmalıdır. İşlemin bayt yönelimli olduğu varsayılır. DLE için kod Hex 90 veya Octal 220'dir (bu ASCII DLE'den farklıdır; ASCII DLE Hex 10 veya Octal 020'dir). [2] ETX Hex 03 veya Octal 03'tür (ASCII ETX ile aynıdır).
2B.3 Type B2 ve BA (tanımlayıcı ve sayım modları)
Type B2 ve BA işlemleri üç alana sahiptir: 9 baytlık (72 bit) bir tanımlayıcı alanı (aşağıda gösterildiği gibi) ve değişken uzunlukta (sıfır dahil) bilgi ve dolgu alanları. Bir işlemin toplam uzunluğu (72 + info + filler) bittir.
||| | ||
| |||||
||
Info count, bilgi alanındaki bit sayısının ikili sayımıdır; tanımlayıcı veya dolgu bitlerini içermez. Info count alanı 24 bit olduğundan bilgi bitlerinin sayısı (2**24 - 1) ile sınırlıdır.
Sequence #, B2, BA ve B4 türü işlemlerin döngüsel sıralı sayımıdır. Sıra numaralarının dahil edilmesi hata ayıklama ve hata kontrolünde yardımcı olur; çünkü sıra numaraları eksik işlemleri kontrol etmek ve hataların yerini belirlemeye yardımcı olmak için kullanılabilir. Bu mekanizmayı uygulamak istemeyen hostlar bu alanda tüm bitleri 1 yapmalıdır. Sayım sıfırdan başlar ve tüm bitler 1 olana kadar sıralı biçimde devam eder; ardından yeniden tüm bitler 0 olacak şekilde sıfırlanır. İzin verilen sıra numaraları öncekinin bir fazlası, tüm bitler 1 ve yalnızca ilk işlem için sıfırdır.
Filler count, anlamlı verinin sonundan sonra dolgu olarak kullanılan (yani bilgi olmayan) bitlerin ikili sayımıdır. Dolgu bitlerinin sayısı filler count alanı 8 bit olduğu için 255 ile sınırlıdır.
NUL baytlarının tamamı 0 içermelidir.
2B.4 Type B3 (mevcut modlar)
Type B3 işlemleri sabit uzunlukta iki bayttır. İlk bayt işlem türü B3'ü tanımlar, ikinci bayt ise alma için mevcut aktarım modlarını tanımlar.
+-----------------+---------------------+
| Type | I receive |
| B3 | |
| |0|0|BA|B2|B9|B1|B8|B0|
+-----------------+---------------------+
Modlar yukarıda gösterildiği gibi bit kodlama ile belirtilir. Belirli bitler mantıksal "1" olarak ayarlanmışsa, ilgili modların gönderenin alıcı tarafı tarafından desteklendiğini gösterir. En yüksek iki anlamlı bit mantıksal "0" olarak ayarlanmalıdır. Mod mevcut işlemleri simplex bağlantılarda anlam taşımaz. Type B3 işlemlerinin kullanımı Bölüm 3B’de ele alınmıştır.
2B.5 Type B4 (bilgi ayırıcı)
Type B4 işlemleri sabit uzunlukta dört bayttır. İlk bayt işlem türü B4’ü tanımlar, ikinci bayt ayırıcıyı tanımlar ve üçüncü ile dördüncü baytlar 16 bitlik bir sıra numarası içerir.
+------------+------------+-------------------------+
| Type | End Code | Sequence Number |
| B4 | | | |
+------------+------------+------------+------------+
Aşağıdaki ayırıcı kodları atanmıştır:
| Hex | Octal | Anlam |
|---|---|---|
| 01 | 001 | Birim ayırıcı |
| 02 | 002 | Kayıt ayırıcı |
| 03 | 003 | Grup ayırıcı |
| 04 | 004 | Dosya ayırıcı |
Dosyalar, gruplar, kayıtlar ve birimler kullanıcı tarafından bu şekilde tanımlanan veri blokları olabilir. Tek kısıtlama hiyerarşik ilişkinin Dosya > Gruplar > Kayıtlar > Birimler olmasıdır (burada ">" "içerir" anlamına gelir). Bu nedenle bir dosya ayırıcı yalnızca dosyanın sonunu değil aynı zamanda grup, kayıt ve birim sonunu da işaretler.
Bu ayırıcılar veri aktarım seviyesinde verinin mantıksal olarak ayrılması için kullanışlı olabilir. Kullanımları uygulama protokolü tarafından belirlenir.
2B.6 Type B5 (Hata Kodları)
Type B5 (hata kodları) işlemleri aşağıda gösterildiği gibi sabit uzunlukta dört bayttır. İlk bayt işlem türü B5’i tanımlar, ikinci bayt bir hata kodunu gösterir ve üçüncü ile dördüncü baytlar hatanın oluştuğu işlemin sıra numarasını gösterebilir.
| Type | Error Code | Sequence Number | Sequence Number |
|---|---|---|---|
| B5 |
Atanmış Hata Kodları
| Error Code (Hex) | Error Code (Octal) | Anlam |
|---|---|---|
| 00 | 000 | Tanımlanmamış hata |
| 01 | 001 | Senkronizasyon kaybı (B0 ile BF arasında olmayan tür kodu). |
| 02 | 002 | Bozuk sıra (sıra numarası alanı beklenen fakat alınmamış ilk sıra numarasını içerir). |
| 03 | 003 | Geçersiz DLF dizisi (DLE DLE veya DLE FTX dışında). |
| B0–BF | 260–277 | İşlem türü (hata kodu tarafından belirtilen) uygulanmamıştır. |
Hata kodu işlemi yalnızca hata kontrolü amacıyla tanımlanmıştır. DTP, hata kodu alan bir alıcının herhangi bir kurtarma eylemi gerçekleştirmesini zorunlu kılmaz. Alıcı hata kodu işlemini yok sayabilir. Ayrıca DTP, sıra numaralarının hatırlanmasını veya iletilmesini zorunlu kılmaz.
2B.7 Type B6 (Abort)
Type B6 (abort) işlemleri aşağıda gösterildiği gibi sabit uzunlukta iki bayttır. İlk bayt işlem türü B6’yı tanımlar, ikinci bayt ise abort işlevini tanımlar.
| Type | Function |
|---|---|
| B6 |
Atanmış Abort Kodları
| Abort Code (Hex) | Abort Code (Octal) | Anlam |
|---|---|---|
| 00 | 000 | Önceki işlemi iptal et |
| 01 | 001 | Önceki birimi iptal et |
| 02 | 002 | Önceki kaydı iptal et |
| 03 | 003 | Önceki grubu iptal et |
| 04 | 004 | Önceki dosyayı iptal et |
DTP, abort alan bir alıcının belirli bir eylem gerçekleştirmesini zorunlu kılmaz; bu nedenle bir gönderici bu konuda herhangi bir varsayımda bulunmamalıdır. Abort işleminin nasıl ele alınacağı daha üst seviyedeki uygulama protokolleri tarafından belirtilmelidir.
2B.8 Type B7 (NoOp)
B7 tipi (NoOp) işlemler bir bayt (8‑bit) uzunluğundadır ve hiçbir işlem yapılmadığını belirtir. Ağ bağlantıları için kullanılan bayt boyutu 8 bitten farklı olduğunda bunlar dolgu olarak yararlı olabilir.
3. İlk Bağlantı, El Sıkışma ve Hata Kurtarma
3A.
DTP, bağlantıların kurulmasında kullanılan mekanizmayı belirtmez. Gereksinimlerine uygun mekanizmayı seçmek uygulama protokolüne (örneğin dosya aktarım protokolü) bırakılmıştır. [3]
3B.
Tam çift yönlü bir bağlantı kurulduktan sonraki ilk işlem, alım için kullanılabilir aktarım kiplerini belirten B3 tipi (kullanılabilir kipler) olacaktır. Kullanılabilir kipler (Type B3) işlemi, simplex bağlantılarda geçerli değildir. Alıcı tarafından kabul edilebilir bir kip seçmek göndericinin sorumluluğundadır. [4] Kabul edilebilir bir kip mevcut değilse veya seçilen kip kabul edilebilir değilse bağlantı kapatılabilir.
3C.
DTP tarafından herhangi bir hata kurtarma mekanizması belirtilmemiştir. Uygulama protokolü hata kurtarma ve ek hata denetim mekanizmaları uygulayabilir.
Son Notlar
[1] İşlem terimi burada, aktarım kipi tarafından tanımlanan bir veri bloğunu ifade etmek için kullanılmıştır.
[2] Bu atama, 128 Network ASCII karakterinin bütünlüğünü koruma TELNET felsefesiyle tutarlı olacak şekilde yapılmıştır.
[3] Bununla birlikte, mümkün olduğunda RFC 165'te belirtilen standart Initial Connection Protocol'ün veya onu izleyen herhangi bir standart belgenin benimsenmesi önerilir.
[4] Mevcut olduğunda göndericinin descriptor and count kipini (Type B2 veya BA) seçmesi önerilir. Indefinite bitstream kipi (Type B0 veya B8) yalnızca diğer iki kip mevcut olmadığında seçilmelidir.
Bu RFC, çevrimiçi RFC arşivlerine eklenmek üzere makine tarafından okunabilir biçime Ryan Kato tarafından 6/01 tarihinde dönüştürülmüştür.