XMODEM - XMODEM

XMODEM
iletişim protokolü
Amaç dosya aktarım Protokolü
Geliştirici(ler) Ward Christensen
tanıtıldı 1977 ; 44 yıl önce ( 1977 )
Etkilenen YMODEM , diğerleri
Donanım modemler

XMODEM , 1977 MODEM.ASM terminal programında kullanılmak üzere Ward Christensen tarafından hızlı bir hack olarak geliştirilmiş basit bir dosya aktarım protokolüdür . Her iki taraf da MODEM kullandığında, kullanıcıların bilgisayarları arasında dosya aktarmalarına izin verdi. Keith Petersen, her zaman "sessiz modu" açmak için küçük bir güncelleme yaptı ve sonucu XMODEM olarak adlandırdı.

XMODEM, çoğu dosya aktarım protokolü gibi, orijinal verileri alıcıya gönderilen bir dizi " paket "e böler ve ek bilgilerle birlikte alıcının bu paketin doğru alınıp alınmadığını belirlemesini sağlar. Bir hata tespit edilirse, alıcı paketin yeniden gönderilmesini ister. Bir dizi hatalı paket, aktarımın iptal edilmesine neden olur.

XMODEM , büyük ölçüde uygulanması kolay olduğu için erken bülten tahtası sistemi (BBS) pazarında son derece popüler hale geldi . Aynı zamanda oldukça verimsizdi ve modem hızları arttıkça, bu sorun, performansı artırmak veya protokolle ilgili diğer sorunları gidermek için bir dizi değiştirilmiş XMODEM sürümünün geliştirilmesine yol açtı. Christensen, orijinal XMODEM'inin "bilgisayar tarihinde en çok değiştirilmiş tek program" olduğuna inanıyordu.

Chuck Forsberg , YMODEM protokolünde bir dizi ortak değişiklik topladı , ancak zayıf uygulama, daha sonraki ZMODEM protokolü tarafından yeniden birleştirilmeden önce daha fazla kırılmaya yol açtı . ZMODEM çok popüler oldu, ancak BBS pazarında XMODEM'in yerini hiçbir zaman tam olarak alamadı.

paket yapısı

Orijinal XMODEM, CP/M disketlerinde kullanılan temel blok boyutu olan 128 baytlık bir veri paketi kullandı . Paketin önüne bir karakter, 0-255 arasında bir "blok numarası" ve "ters" blok numarası - 255 eksi blok numarası içeren basit bir 3 baytlık başlık eklenmiştir. Blok numaralandırma, gönderilen ilk blok için 0 ile değil 1 ile başlar. Başlığı 128 baytlık veri ve ardından tek baytlık bir sağlama toplamı izledi . Bu nedenle tam paket, yaklaşık %97'lik bir toplam kanal verimliliği için 128 bayt veri yükü verisi içeren 132 bayt uzunluğundaydı . <SOH>

Sağlama toplamı, modulo 256 paketindeki tüm baytların toplamıydı. Modulo işlemi, sonucun en az anlamlı olan sekiz biti dışında tümü atılarak veya alternatif olarak , aynı sonucu üretecek aritmetik taşmayı yok sayarak sekiz bitlik bir makinede kolayca hesaplandı. otomatik olarak etki eder. Bu şekilde, sağlama toplamı sekiz bitlik bir miktarla sınırlandırıldı. Örneğin, bu sağlama toplamı yöntemi, 130 ve 130 değerlerini taşıyan yalnızca iki bayt içeren küçük bir veri paketinde kullanılmışsa, bu kodların toplamı 260'tır ve sonuçta elde edilen sağlama toplamı 4'tür.

Dosya, son bloktan sonra gönderilen bir karakterle "tamamlandı" olarak işaretlendi . Bu karakter bir pakette değildi, tek başına tek bir bayt olarak gönderildi. Dosya uzunluğu protokolün bir parçası olarak gönderilmediğinden, son paket bırakılabilecek bir "bilinen karakter" ile dolduruldu. Orijinal spesifikasyonda, bu varsayılan olarak 26 ondalık sayıya ayarlandı ve CP/M, kendi disk formatı içinde dosya sonu işaretçisi olarak kullandı. Standart, herhangi bir karakterin dolgu için kullanılabileceğini önerdi, ancak protokolün kendi içinde değiştirilmesinin bir yolu yoktu - bir uygulama dolgu karakterini değiştirmişse, yalnızca aynı uygulamayı kullanan istemciler yeni dolgu karakterini doğru şekilde yorumlayacaktır. <EOT><SUB>

Aktarım ayrıntıları

Dosyalar bir seferde bir paket aktarıldı. Alındığında, paketin sağlama toplamı alıcı tarafından hesaplanır ve paketin sonunda göndericiden alınanla karşılaştırılır. Eğer ikisi eşleşirse, alıcı gönderene bir mesaj gönderir ve gönderici de bir sonraki paketi sırayla gönderir. Sağlama toplamı ile ilgili bir sorun varsa, alıcı bunun yerine bir . Bir a alınırsa , gönderen paketi yeniden gönderir ve aktarımı iptal etmeden önce normalde on olmak üzere birkaç kez denemeye devam ederdi. <ACK><NAK><NAK>

<NAK>Alıcı, <EOT>karakter eksikliği nedeniyle veri beklerken on saniye içinde geçerli bir paket almazsa da A gönderildi . Paket içinde , paketin ortasındaki bağlantıların kesilmesine karşı koruma sağlayan yedi saniyelik bir zaman aşımı da kullanıldı .

Blok numaraları da hataları kontrol etmek için basit bir şekilde incelendi. Bir paketi başarıyla aldıktan sonra, bir sonraki paketin bir yüksek numarası olmalıdır. Bunun yerine aynı blok numarasını aldıysa, bu ciddi <ACK>olarak kabul edilmedi, gönderici tarafından alınmadığı ve daha sonra paketi yeniden gönderdiği ima edildi. Diğer herhangi bir paket numarası, paketlerin kaybolduğunu gösterir.

Aktarımlar alıcı odaklıydı; verici <NAK>, alıcı tarafından bir ilk gönderilinceye kadar herhangi bir veri göndermeyecektir . Bu, kullanıcının uzaktan konumlandırılacak olan gönderen makineyle etkileşim kurma biçiminin mantıklı bir sonucuydu. Kullanıcı, gönderen makinede istenen dosyaya gider ve ardından o makineden dosyayı aktarmasını ister. Bu komut bir kez verildikten sonra, kullanıcı yerel yazılımında almaya başlamak için bir komut yürütür. Uzak sistemden dosyayı isteme ile yerel bir komut alma komutu verme arasındaki gecikme bilinmediğinden, XMODEM alıcının veri paketleri için istek göndermeye başlaması için 90 saniyeye kadar izin verdi.

sorunlar

XMODEM, 1982'de bir gazetecinin Pakistan'dan Amerika Birleşik Devletleri'ne Osborne 1 ve düşük kaliteli telefon hatları üzerinden akustik birleştirici ile hikayeleri iletecek kadar sağlam olmasına rağmen , protokolün birkaç kusuru vardı.

Küçük problemler

XMODEM, CP/M makineleri için yazılmıştır ve bu işletim sisteminin birkaç işaretini taşır . Özellikle, CP/M'deki dosyalar her zaman 128 baytın katlarıydı ve sonları <EOT>karakterle bir blok içinde işaretlendi . Bu özellikler doğrudan XMODEM'e nakledildi. Bununla birlikte, diğer işletim sistemleri bu özelliklerden hiçbirine sahip değildi ve 1980'lerin başlarında MS-DOS'un yaygın bir şekilde tanıtılması, XMODEM'in dosya sonu işaretçisini <EOT> veya <EOF> sonunu fark edecek şekilde güncellenmesine neden oldu .

Bir süredir , alıcı uçtan aktarımı kolayca iptal etmek için veya <CAN>yerine bir karakter göndermenin desteklenmesi önerildi . Aynı şekilde, göndericinin belirtilen yerine alınan bir transferi iptal etmek istediğini belirtti. Ancak, bu karakter kolayca olması gerekiyordu ne basit gürültü ile ilgili hatalar aracılığı "oluşturulmuş" olabilir veya . Bu sorunu önlemek için bir çift- önerildi, ancak bunun yaygın olarak uygulanıp uygulanmadığı açık değil. <ACK><NAK><CAN><SOH><ACK><NAK><CAN>

Ana problemler

XMODEM, zaten oldukça nadir olan diğer dosya aktarım protokolleri hakkında fazla bilgi sahibi olmadan basitlik için tasarlanmıştır. Basitliği nedeniyle, bir aktarımın başarısız olmasına veya daha kötüsü, protokol tarafından farkedilmeyen yanlış bir dosyaya neden olabilecek çok sayıda temel hata vardı. Bunun çoğu, iki bitin ters çevrilmesi durumunda verilerdeki eksik hatalara duyarlı olan ve uygun şekilde kısa bir gürültü patlamasıyla gerçekleşebilen hata düzeltme için basit bir sağlama toplamının kullanılmasından kaynaklanıyordu . Ek olarak, başlıkta veya sağlama toplamında benzer bir hasar, verilerin kendisinin zarar görmediği durumlarda başarısız bir aktarıma neden olabilir.

Birçok yazar, bu ve diğer sorunları çözmek için XMODEM'e uzantılar getirdi. Birçoğu, bu uzantıların yeni bir XMODEM standardının parçası olarak dahil edilmesini istedi. Ancak, Ward Christensen bunu yapmayı reddetti, çünkü tam olarak bu özelliklerin eksikliği ve XMODEM'in yaygın kullanımına yol açan ilgili kodlamanın bunları desteklemek için gerekli olması. Açıkladığı gibi:

Diğer insanlarla iletişim kurmak için kişisel bir ihtiyacı karşılamak için (yaptığım her şey gibi) çok plansız bir şekilde bir araya getirdiğim hızlı bir hack oldu. SADECE 8/77'de yapılmış olması ve hemen kamuya açık hale getirmem, bunu standart hale getirdi...
...'tam dupleks', 'birden fazla bekleyen blok', 'birden çok hedef', vb. gibi protokolde ÖNEMLİ değişiklikler yapmamı öneren kişiler, protokolün inanılmaz basitliğinin sebeplerden biri olduğunu anlamıyorlar. hayatta kaldı.

Toplu Transferler

XMODEM ile ilgili bir başka sorun da, aktarımın otomatik olmaktan ziyade kullanıcı tarafından yönlendirilmesini gerektirmesiydi. Tipik olarak bu, kullanıcının istediği dosyayı seçmek için gönderenin sisteminde gezineceği ve ardından bu sistemi "göndermeye hazır" moduna geçirmek için bir komut kullanacağı anlamına geliyordu. Daha sonra, uçbirim öykünücüsünde bir komut kullanarak aktarımı kendi uçlarından tetiklerler. Kullanıcı başka bir dosya aktarmak isterse, bu işlemi tekrarlamak zorunda kalacaktı.

İki site arasında otomatik aktarımlar için, zaman içinde XMODEM protokolüne bir dizi eklenti uygulandı. Bunlar genellikle gönderenin dosya üstüne dosya göndermeye devam edeceğini ve alıcının bir aktarımın başlangıcında normal olarak bir NAK göndererek bir sonraki dosyayı tetiklemeye çalıştığını varsayıyordu . Ne zaman NAK s aşımına, ya orada artık dosyalarıydı veya bağlantı zaten kırılmış olduğu varsayılabilir.

MODEM7

MODEM7 toplu veya Toplu XMODEM olarak da bilinen MODEM7 , XMODEM protokolünün bilinen ilk uzantısıydı. Normal bir XMODEM dosya aktarımı, alıcının gönderene tek bir NAK karakteri göndermesiyle başlar, ardından verinin başladığını ve ardından veri paketlerini belirtmek için tek bir SOH göndermeye başlar .

MODEM7, dosya adını 8.3 dosya adı biçiminde <SOH>. Her karakter ayrı ayrı gönderildi ve alıcı tarafından bir hata düzeltme biçimi olarak yankılanması gerekiyordu. Farkında olmayan bir XMODEM uygulaması için, SOH'nin gelmesini beklerken bu veriler basitçe yoksayılır , böylece karakterler yankılanmaz ve uygulama geleneksel XMODEM'e geri dönebilir. "Aware" yazılımıyla, dosyayı yerel olarak kaydetmek için dosya adı kullanılabilir. Aktarımlar başka bir <NAK> ile devam edebilir , her dosya alıcıya gönderilen ad altında kaydedilir.

Jerry Pournelle 1983'te MODEM7'yi "muhtemelen var olan en popüler mikrobilgisayar iletişim programı" olarak tanımladı.

TeLink

MODEM7, dosya adını normal metin olarak gönderdi; bu, XMODEM'in kaçınmaya çalıştığı aynı sorunlardan dolayı bozulabileceği anlamına geliyordu. Bu , orijinal FidoNet postalarının yazarı Tom Jennings tarafından TeLink'in tanıtımına yol açtı .

TeLink, orijinal dosya hakkında bilgi içeren yeni bir "sıfır paketi" standartlaştırarak MODEM7'nin sorunlarını önledi. Bu, normal bir 128 baytlık XMODEM bloğuna yerleştirilen dosyanın adını, boyutunu ve zaman damgasını içeriyordu. Normal bir XMODEM aktarımı, göndericinin bir <SOH> başlığıyla "blok 1" göndermesiyle başlarken, TeLink başlık paketi "blok 0" olarak etiketlendi ve bir <SYN> ile başladı . Paket, dosya oluşturma tarih ve saatini, 16 karaktere kadar dosya adını, 4 baytlık dosya boyutunu ve dosyayı gönderen programın adını içeriyordu.

Normal bir XMODEM uygulaması, paket numarasının bozulmuş olduğu varsayımıyla paketi basitçe atar. Ancak bu, paket atılırsa potansiyel bir zaman gecikmesine yol açtı, çünkü gönderici , sıfır paketi anlamadığı veya bir iletim hatası olduğu için alıcının bir <NAK> ile yanıt verip vermediğini anlayamadı. TeLink normalde yalnızca FidoNet standartlarının bir parçası olarak talep eden FidoNet yazılımı tarafından kullanıldığından , her iki uç da her zaman bu standardı destekleyeceğinden, bu gerçek bir dünya sorunu teşkil etmiyordu.

Temel "blok 0" sistemi FidoNet topluluğunda bir standart haline geldi ve SEAlink ve YMODEM gibi bir dizi gelecekteki protokol tarafından yeniden kullanıldı .

XMODEM-CRC

Orijinal protokolde kullanılan sağlama toplamı son derece basitti ve paket içindeki hatalar fark edilmeyebilirdi. Bu , 8 bitlik sağlama toplamı yerine 16 bitlik bir CRC kullanan John Byrns tarafından XMODEM-CRC'nin tanıtılmasına yol açtı . CRC'ler yalnızca paketteki verileri değil, aynı zamanda konumunu da kodlayarak bir sağlama toplamının kaçıracağı bit değiştirme hatalarını fark etmesini sağlar. İstatistiksel olarak, bu, 16 bitten daha kısa bir hatayı %99,9969 ve daha uzun hata bit dizileri için daha da yüksek bir hata tespit etme şansını sağladı.

XMODEM-CRC, XMODEM ile geriye dönük olarak uyumlu olacak şekilde tasarlanmıştır. Bunu yapmak için alıcı , aktarımı başlatmak için Ca yerine bir (büyük C) karakteri gönderdi <NAK>. Gönderici bir paket göndererek yanıt verdiyse, gönderenin XMODEM-CRC'yi "bildiği" varsayılır ve alıcı C's göndermeye devam eder . Hiçbir paket gelmiyorsa, alıcı gönderenin protokolü bilmediğini varsayar ve <NAK>"geleneksel" bir XMODEM aktarımı başlatmak için bir mesaj gönderir .

Ne yazık ki, bu geriye dönük uyumluluk girişiminin bir dezavantajı vardı. İlk Ckarakterin kaybolması veya bozulması olası olduğundan, ilk aktarımı tetikleme girişimi başarısız olursa alıcının XMODEM-CRC'yi desteklemediği varsayılamaz. Böylece alıcı C, her deneme arasında üç saniye bekleyerek aktarımı üç kez başlatmaya çalıştı . Bu, amaçlandığı gibi, kullanıcı herhangi bir XMODEM ile konuşmaya çalışırken XMODEM-CRC'yi seçerse , aktarım başlamadan önce potansiyel 10 saniyelik bir gecikme olduğu anlamına geliyordu .

Gecikmeyi önlemek için, gönderici ve alıcı genellikle XMODEM-CRC'yi XMODEM'den ayrı olarak listeler ve gönderen açıkça listelemediyse kullanıcının "temel" XMODEM'i seçmesine izin verir. Ortalama bir kullanıcı için, XMODEM-CRC esasen bir "ikinci protokol"dü ve bu şekilde ele alındı. Ancak bu, CRC'nin tüm TeLink aktarımları için standart olarak tanımlandığı FidoNet postaları için geçerli değildi.

Daha yüksek verim

XMODEM protokolü göndericinin durup alıcıdan bir <ACK>veya <NAK>mesaj beklemesini gerektirdiğinden, oldukça yavaş olma eğilimindeydi. 300 bit/s modem çağında, 132 baytlık paketin tamamının gönderilmesi 3.5 saniyenin biraz üzerinde bir süre gerektiriyordu (132 bayt * (bayt başına 8 bit + 1 başlangıç ​​biti + 1 durdurma biti) / saniyede 300 bit). Alıcının <ACK>gönderene geri dönmesinin 0,2 saniye ve bir sonraki paketin alıcıya çarpmaya başlamasının (her iki yönde 0,1 saniye) sürdüğünü varsayarsak , bir paketin toplam süresi 3,7 saniye, yani %92'nin biraz üzerinde olacaktır.

Modem hızları arttıkça, <ACK>/ göndermek için gereken sabit gecikme <NAK>, paketi göndermek için gereken zamanla orantılı olarak büyüdü. Örneğin, 2400 bit/s'de paketlerin gönderilmesi yalnızca 0,44 saniye sürdü, bu nedenle <ACK>/'nin <NAK>geri gelmesi 0,2 saniye sürdüyse (bu, aktarım hızı değil ağdaki gecikmedir ), aktarım hızı %60'ın altına düşmüştür. 9600 bit/s'de %30'un altındadır – yanıtı beklemek için paketi göndermek için gerekenden daha fazla zaman harcanır.

Bu sorunları gidermek için bir dizi yeni XMODEM sürümü tanıtıldı. Daha önceki uzantılar gibi, bu sürümler orijinal XMODEM ile geriye dönük uyumlu olma eğilimindeydi ve bu uzantılar gibi, bu, kullanıcının terminal öykünücüsünde XMODEM manzarasının daha da kırılmasına yol açtı. Sonunda XMODEM'in onlarca versiyonu ortaya çıktı.

WXModem

"Windowed Xmodem"in kısaltması olan WXmodem , Peter Boswell tarafından 1986'da yüksek gecikmeli hatlarda, özellikle genel X.25 sistemlerinde ve PC Pursuit'te kullanılmak üzere geliştirilen bir XMODEM çeşididir . Bunlar, düz eski telefon hizmetinden çok daha yüksek gecikmelere sahiptir ve bu da XMODEM'de çok düşük verimliliğe yol açar. Ek olarak, bu ağlar genellikle akış kontrolü ve diğer görevler için kontrol karakterlerini kullanır , özellikle XON/XOFF veri akışını durduracaktır. Son olarak, yeniden göndermeyi gerektiren bir hata durumunda, bazen bir SOH'nin bir paket göstergesi mi yoksa daha fazla gürültü mü olduğunu bilmek zordu . WXmodem, bu sorunları gidermek için XMODEM-CRC'yi uyarladı.

Değişikliklerden biri, DLE , XON , XOFF ve SYN adlı küçük bir kontrol karakter kümesinden kaçmaktı . Bunlar önlerine bir DLE yerleştirilerek ve ardından karakter 64 ile XORing yapılarak değiştirilerek kaçıldı. Teoride bu, paketin orijinal olarak tamamen kaçılması gereken karakterlerden oluşuyorsa 264 bayt kadar uzun olabileceği anlamına geliyordu. Bu eklenen ve değiştirilen karakterler CRC hesaplamasının bir parçası değildir, CRC'yi hesaplamadan önce alıcı uçta kaldırılır ve dönüştürülür.

Ek olarak, tüm paketlerin önüne bir SYN karakteri getirildi , bu da paket girişinin SYN SOH olduğu anlamına geliyordu, bu da çeşitli hata durumlarında başıboş bir SOH'nin bir paket başlığıyla karıştırılması olasılığını azaltıyordu . Bir paketin gövdesinde bulunan çıkış yapılmamış bir SYN bir hataydı .

WXMODEM'deki en büyük değişiklik , yüksek gecikmeli bağlantılarda verimi artırmak için kayan bir pencerenin kullanılmasıdır . Bunu yapmak için, ACK mesajlarını ACK veya NAK yaptıkları paket numarası takip etti . Alıcının her paketi ACK yapması gerekmez, bir ile dört paket arasında herhangi bir sayıda ACK yapmasına izin verilir . Bir ACK dördüncü paketi dizi numarasına varsayılır ACK dört paket. Bir hata, NAK'ın bu numaradan gelen tüm paketlerle ve yeniden gönderildikten hemen sonra gönderilmesine neden olur.

Her dört pakette bir ACK gerekmesi , sistemin 512 baytlık bir paket boyutu varmış gibi çalışmasını sağlar, ancak bir hata durumunda, genellikle yeniden gönderilmesi için yalnızca 128 bayt gerekir. Ayrıca, ters yönde akan veri miktarını dört kat azaltır. Bu, tipik modemin tam dupleks işleminde pek ilgi çekici değildir , ancak Telebit modelleri gibi bir yönde 19 kB hıza ve dönüş kanalında 75 bit/sn hıza sahip yarım dupleks sistemlerde önemlidir .

DENİZ bağlantısı

FidoNet sistemi için ilk üçüncü taraf posta göndericilerinden biri , o zamanlar popüler olan .arc veri sıkıştırma biçimiyle aynı yazar tarafından yazılan SEAdog'du . SEAdog, WXmodem ile aynı kayar pencere konseptine dayalı geliştirilmiş bir transfer protokolü olan SEAlink dahil olmak üzere çok çeşitli iyileştirmeler içeriyordu. Çoğunlukla detaylarda WXmodem'den farklıydı.

Bir fark, SEAlink'in, başlığın beklendiği FidoNet sistemlerinde TeLink'in yerine bir yedek olarak çalışması için gerekli olan TeLink tarafından sunulan "sıfır paketi" desteklemesidir. ACK'ler ve NAK'lar , orijinal XMODEM paket başlığıyla aynı şekilde , ACK veya NAK , ardından paket numarası, ardından paket numarasının tümleyeni ile başlayarak üç baytlık "paketlere" genişletildi . Pencere boyutu normalde altı pakete ayarlandı.

SEAlink'in X.25 veya benzeri bağlantılar üzerinden çalışması beklenmiyordu ve bu nedenle kaçış gerçekleştirmedi. Bu standart WXmodem'in yeniden amaçladığı SYN karakterini kullandığından, sıfır paketin düzgün çalışması için buna da ihtiyaç vardı. Bu değişikliklerin üzerine, yarı çift yönlü bağlantılar için bir "Overdrive" modu ekledi. Bu, başarıyla aktarılan paketler için ACK'leri bastırdı ve aslında pencereyi sonsuz boyutta yaptı. Bu mod, sıfır bloğunda bir bayrakla belirtildi.

SEAlink daha sonra bir dizi başka iyileştirme ekledi ve kullanışlı bir genel amaçlı protokoldü. Ancak, FidoNet dünyasının dışında nadir kaldı ve kullanıcıya yönelik yazılımlarda nadiren görüldü.

XMODEM-1K

Verim sorununu çözmenin başka bir yolu da paket boyutunu artırmaktır. Temel gecikme sorunu devam etse de, sorun haline gelme hızı daha yüksektir. 1024 baytlık paketlere sahip XMODEM-1K, bu tür en popüler çözümdü. Bu durumda, yukarıdakiyle aynı varsayımlar göz önüne alındığında, 9600 bit/s'deki verim %81'dir.

XMODEM-1K uzun blok boyutu belirtilen XMODEM-CRC genişletilmiş bir versiyonu olan gönderici olan bir paket başlatarak <STX>karakteri yerine <SOH>. Diğer geriye dönük uyumlu XMODEM uzantıları gibi, diğer uçta herhangi bir XMODEM uygulamasıyla -1K aktarımının başlatılabilmesi ve gerektiğinde özelliklerin geri alınması amaçlandı.

XMODEM-1K aslen getirdiği XMODEM birçok iyileştirmeler biriydi Chuck Forsberg onun içinde YMODEM protokolü. Forsberg, çeşitli iyileştirmelerin isteğe bağlı olduğunu ve yazılım yazarlarının mümkün olduğunca çoğunu uygulamalarını beklediğini öne sürdü. Bunun yerine, genellikle asgariyi uyguladılar, bu da yarı uyumlu uygulamaların bolluğuna ve nihayetinde "YMODEM" adının "XMODEM-1K" ve çeşitli YMODEM'lere bölünmesine yol açtı. Böylece XMODEM-1K, aslında YMODEM'den sonra bir tarih verdi, ancak yine de oldukça yaygın kaldı.

NMODEM

NMODEM, 1990 yılında yayınlayan LB Neal tarafından geliştirilen bir dosya aktarım protokolüdür. NMODEM, esasen XMODEM'in 128 baytlık bloklarının aksine daha büyük 2048 baytlık bloklar kullanan bir XMODEM-CRC sürümüdür. NMODEM, IBM PC uyumlu bilgisayar ailesi için Turbo Pascal 5.0 ile yazılmış ayrı bir program olarak uygulandı . Blok boyutu, çağdaş sabit sürücülerdeki MS-DOS FAT dosya sisteminin ortak küme boyutuyla eşleşecek şekilde seçildi , bu da verileri yazmak için arabelleğe almayı daha basit hale getirdi.

Protokol sahtekarlığı

Güvenilir (hatasız) bağlantılar üzerinden, daha genel olarak " protokol sahtekarlığı " olarak bilinen bir teknik olan paketleri "önceden kabul ederek" gecikmeyi ortadan kaldırmak mümkündür . Bu normalde bağlantı donanımında, özellikle Telebit modemlerde gerçekleştirilir. Seçenek açıldığında modemler, XMODEM başlığını fark eder ve hemen bir ACK gönderir . Bu, gönderen XMODEM programının bir sonraki paketi hemen göndermesine neden olarak, aktarımı sonsuz boyutlu bir pencere gibi sürekli hale getirir. Modemler de bastırmak ACK böylece düşük hızda dönüş kanalı serbest bırakarak, ucunda XMODEM yazılımı tarafından gönderilen.

Sistem ayrıca protokolün kendisinde de uygulanabilir ve XMODEM'in varyasyonları bu özelliği sunar. Bu durumlarda, alıcı göndereceğini ACK paketi başlayınca TELEBIT modemler aynı şekilde, kısa sürede. Bu özellik yalnızca alıcı tarafı davranışının bir değişikliği olduğundan, gönderici tarafında protokolde herhangi bir değişiklik gerektirmez. YMODEM bu sistemi resmileştirdi.

Bu kavram, bağlantının her iki tarafındaki davranışı değiştiren SEAlink'te kullanılanla karşılaştırılmalıdır. Sealink olarak, alıcı göndermeyi durdurur ACK tamamen ve gönderen bunları beklemeyin onun davranışını değiştirir.

Ayrıca bakınız

Referanslar

alıntılar

bibliyografya

Dış bağlantılar