Geliştirilmiş Ağ İşletimi İçin Üç Yardım
Network Working Group
J. McQuillan
Request for Comments: 381
D. Walden
NIC: 11151
Bolt Beranek and Newman Inc.
26 Temmuz 1972
1. Planlı Yazılım Bakımı
ARPA Ağı büyüdükçe, gerekli yeni yazılımların kimseyi aksatmadan ağa dahil edilebileceği zamanları bulmakta zorlandığımızı gördük. Örneğin, MIT’deki makineler arasında her zaman tesis içi trafik vardır ve AMES TIP ile IMP arasında da neredeyse her zaman trafik bulunmaktadır — ARPA Ağı’nda güneş hiç batmaz. Plansız kesintileri en aza indirmek ve aynı zamanda yapmamız gereken işleri yapabilmemizi sağlamak için, IMP’lerin yeniden yüklenebileceği bir zaman olarak her Salı doğu saatiyle 7.00–8.00 arasını planlamayı öneriyoruz. Bu süreyi muhtemelen her Salı kullanmayacağız, ancak her Salı için bu zamanı ayırıyoruz. Yukarıda belirtilen süre, her bir sitede donanım önleyici bakımı için halihazırda aylık olarak planlanan birkaç saate ek niteliğindedir.
Bir ağ kullanıcısı, kendi makinesinin ne zaman bakım için planlandığını bilmiyor olabileceğinden ya da Salı sabahı yazılım süresini unutup çalışmaya devam edebileceğinden, IMP-Going-Down IMP-to-Host kontrol iletisini genelleştirmeyi ve kullanıcılara hatırlatma amacıyla kullanılabilmesini öneriyoruz. (Aşağıda ayrıntılı olarak açıklanan) bu ileti, IMP’nin m adet beş dakikalık süre sonra, n adet beş dakikalık süre boyunca, belirli bir nedenle devre dışı kalacağını belirten bilgileri içerecektir. Host’lar (ve TIP), bu bilgileri kullanarak tüm Ağ kullanıcılarını, belirtilen sürenin sonunda IMP’nin kapanacağı konusunda uyarmalıdır.
Zaman zaman bir IMP’yi yeniden başlatmak veya yeniden yüklemek için acil bir neden ortaya çıkabilir. Örneğin, bir sitedeki üç Host düzgün çalışırken bir Host IMP ile iletişim kuramayabilir. Bu tür bir durum bazen IMP’nin yeniden başlatılmasını gerektirir. Böyle bir yeniden başlatma, çalışan kullanıcıların işlerini kaydedebilmeleri ve IMP tekrar çalışır duruma geldiğinde devam edebilmeleri için birkaç dakika öncesinden bir IMP-Going-Down Mesajı ile bildirilecektir.
Bu iki durumda da, ayrıca bir IMP’nin o kadar kötü performans gösterdiği ve hızla kapatılmasının gerektiği durumlarda, IMP kapanmadan yaklaşık 30 saniye önce Host’a tip 2 bir IMP-to-HOST mesajı gönderilecektir. Son olarak, elbette, IMP’nin o kadar hızlı çöktüğü ve hiçbir uyarı verilemediği durumlar da olabilir; ancak IMP hiçbir zaman bilerek bu şekilde kapatılmayacaktır.
2. IMP-to-Host İletişimi
Uzun zamandır, IMP-to-Host hata mesajlarının yeterince kesin olmadığı ya da tamamen belirsiz olduğu yönünde şikayetler bulunmaktadır. RFC #312’de bazı ek hata mesajları önermiştik. Bunlar ve diğer IMP-to-Host mesaj değişiklikleri 14 Ağustos 1972 tarihinde uygulanacaktır ve Host’ların NCP’lerini o tarihe kadar uygun şekilde değiştirmelerini teşvik ediyoruz. Değiştirilmemiş NCP’ler bu değişiklikten sonra da muhtemelen çalışmaya devam edecektir, ancak her site bu konuyu dikkatle incelemelidir. Aşağıdaki tablo tüm IMP-to-Host mesajlarını listelemekte ve yapılacak değişiklikleri açıkça göstermektedir.
IMP-to-Host Mesaj Türleri
| Tür | Eski Anlam | Yeni Anlam |
|---|---|---|
| 0 | Normal Mesajlar | Aynı |
| 1 | Kimliksiz hata | Host-to-IMP Mesajı Liderinde Hata |
| Bitler 31,32=00 – IMP’nin hata flip-flop’u, IMP’nin tanımlayamadığı bir Host-to-IMP mesajının ilk 32 biti üzerinde ayarlanmıştır | ||
| Bitler 31,32=01 – Host-to-IMP mesajı çok kısa (32 bitten az) | ||
| Bitler 31,32=10 – geçersiz Host-to-IMP kodu | ||
| 2 | IMP Kapanıyor | IMP Kapanıyor |
| Bitler 17–32 aşağıdaki gibi kodlanmıştır: | ||
| Tüm bitler sıfır – 30 saniye içinde kapanıyor. | ||
| Bitler 17,18=01 – planlı donanım önleyici bakımı | ||
| Bitler 17,18=10 – planlı yazılım yeniden yükleme | ||
| Bitler 17,18=11 – acil yeniden yükleme veya yeniden başlatma | ||
| Bitler 19–22 – IMP’nin ne kadar süre sonra kapanacağı, 5 dakikalık birimler halinde | ||
| Bitler 23–32 – IMP’nin ne kadar süre kapalı kalacağı, 5 dakikalık birimler halinde | ||
| 3 | Engellenmiş Bağlantı | Atanmamış |
| 4 | NOF | Aynı |
| 5 | RFNM | Aynı |
| 6 | Bağlantı Tablosu Dolu | Atanmamış |
| 7 | Hedef Ölü | Hedef Ölü |
| Bit 32=0 – hedef IMP ölüdür, ulaşılamıyordur ya da mevcut değildir | ||
| Bit 32=1 – hedef Host ölüdür ya da mevcut değildir | ||
| 8 | Kimlikli hata | Host-to-IMP Mesajı Verisinde Hata |
| Verilen kaynak ve bağlantı ile tanımlanan bir Host-to-IMP mesajının veri bitleri üzerinde IMP’nin hata flip-flop’u ayarlanmıştır | ||
| 9 | Eksik İletim | Eksik İletim |
| Bitler 31,32=00 – hedef Host mesajı uzun süre almadı | ||
| Bitler 31,32=01 – Host-to-IMP mesajı çok uzun (8095 bitten fazla) | ||
| Bitler 31,32=10 – Host-to-IMP mesajı çok yavaştı. Son mesaj, ilk bit ile son bit arasında 15 saniyeden fazla sürdü ve atıldı | ||
| Bitler 31,32=11 – Host-to-IMP mesajı alt ağda kayboldu | ||
| 10 | Atanmamış | IMP-Host Arayüzü Sıfırlama |
| IMP’nin hazır hattı düşürülmüş ve Host’a yönelik bekleyen çıktı atılmıştır (muhtemelen Host’un uzun süre IMP’den gelen mesajları almamış olması nedeniyle). IMP, bir sonraki Host-to-IMP mesajının tamamlanmasının ardından alt türü 0 olan bir tip 1 mesajı döndürecektir. |
Değişikliklerin Özeti
- Artık her bir Host-to-IMP normal mesajına karşılık yalnızca bir adet IMP-to-Host mesajı bulunmaktadır.
- 1, 2, 7 ve 9 numaralı mesaj türleri artık ek bilgi taşımaktadır.
- 10 numaralı mesaj türü eklenmiştir.
- 3 ve 6 numaralı mesaj türleri kaldırılmıştır.
3. Ağ Haber Servisi
Bir Ağ haber servisi devreye alınmıştır. TIP kullanıcıları haberlere TIP komutu @NEWS yazarak erişebilirler. Diğer Host’ların kullanıcıları ise BBN Tenex üzerindeki 15600031 (sekizlik) soketine ICP yaparak haberlere ulaşabilirler.
Ağın işletimini iyileştirmeye yönelik başka önerileriniz varsa, görüşlerinizi iletmenizi rica ederiz.
[Bu RFC, çevrimiçi RFC arşivlerine girilmek üzere makine tarafından okunabilir biçime Lorrie Shiota tarafından 08/00 tarihinde dönüştürülmüştür]