SERİ İLETİŞİMDE BAYT KAÇIŞLAMA
Bir ayırıcı aynı zamanda nasıl veri olabilir?
Seri alıcı karakterleri görürken uygulamanın mesajları belirlemesi gerekir. SLIP, kaçışlanmamış END bir paketi sınırlayabilsin diye veri yükündeki C0 ve DB değerlerini iki baytlık dizilerle kaçışlar. Alıcı, okuma işlemleri arasında durumunu koruyarak bu eşlemeyi tersine çevirir. Bu belirli değerler SLIP'e aittir ve kendiliğinden hata denetimi veya güvenlik sağlamaz.
Karakter ve paket
Bir karakter sınırı tek başına bir uygulama mesajını belirlemez.
Özel veri değerlerini kaçışlayın
SLIP, veri yükündeki özel baytları iki baytlık dizilerle temsil eder.
Durumu koruyun
Bir okuma işlemi DB'den sonra sona erse bile ayrıştırıcı kaçış durumunu korumalıdır.
Uç noktaları ve kapsamı belirleyin.
Gerçekte kullanılan protokolü ve ayarları teyit edin.
Yetki kapsamında, zararsız verilerle test edin.
Seçim ve doğrulama kontrol listesi — genişlet
Protokolü ve yakalama katmanını doğrulayın; sıradan ve özel baytları test edin; bölünmüş okumaları, yinelenen işaretçileri ve hata işlemeyi yetkili bir ortamda doğrulayın.
Seri hat bir bayt akışı iletir. Alıcı program bir mesajın nerede bittiğini nasıl bilir? Yaklaşımlardan biri, bir işaretçi ayırmaktır. Ancak bir ölçüm veya dosya aynı bayt değerini içerebilir ve bu değerin değiştirilmeden gönderilmesi yanlışlıkla sonlandırma olarak yorumlanabilir. Bayt kaçışlama bu belirsizliği giderir. Bunu anlamak için yalnızca baud hızına bakmak yerine karakter alımını, paket sınırlarını ve uygulama düzeyindeki anlamı birbirinden ayırın.
Doğru karakterler kendiliğinden bir paket oluşturmaz
Yaygın bir asenkron seri arayüz, bir karakteri belirlemek için başlangıç biti, veri bitleri ve durdurma bitleri kullanır. Karakterler bir programa ulaştığında bir bayt dizisi oluşturur. Alıcı, bir sıcaklık okumasının nerede başlayıp nerede bittiğini kendiliğinden bilmez. Karakter sınırları ve tam mesaj sınırları ayrı sorunlardır.
Bir uygulama protokolü, mesajları sınırlamak için sabit uzunluk, uzunluk alanı, zamanlama veya özel işaretçiler kullanabilir. Her birinin koşulları ve ödünleşimleri vardır. Bu makale, işaretçileri ve kaçışlamayı açıklamak için basit bir seri çerçeveleme örneği olan SLIP'i kullanır. Her seri protokolün SLIP kullandığını veya mevcut bir protokolün gelişigüzel değiştirilmesi gerektiğini öne sürmez.
Feichang'ın FCT-1100-F1S1 tek portlu, üçü bir arada seri cihaz sunucusu, seri iletişimden ağa aktarım için gerçek bir bağlam sunar. Bir arayüz veya ağ üzerinden iletilen baytlar kendiliğinden yeni bir iş anlamı kazanmaz. Bu makale, ürünün dahili çerçeveleme protokolü hakkında çıkarım yapmaz; gerçek yetenekleri için belgelere ve yapılandırmaya bakın.
Bir işaretçi neden iki role sahip olabilir?
Her iki uç noktanın da belirli bir baytın bitişi işaretlediği konusunda anlaştığını varsayalım. Ayrıştırıcı bu baytı aldığında, öncesinde arabelleğe alınmış verileri teslim eder. Bu fikir, bir cümlenin sonunu belirten noktalama işaretine benzer. Ancak ikili içerik herhangi bir bayt değerini içerebilir; seçilen hiçbir değerin veri yükünde bulunmayacağı kendiliğinden garanti değildir.
Bir ölçüm kaydı, bitiş işaretçisiyle aynı değeri içerebilir. Ayrıştırıcı bu değerin o konumdaki kullanımını veri olarak mı yoksa sınır olarak mı ele almalıdır? Değer tek başına her iki soruya da yanıt veremez. Gönderici ve alıcı, özel değerlerin hat üzerinde nasıl temsil edildiğini değiştiren ortak bir kurala ihtiyaç duyar.
Bir değeri yalnızca yasaklamak, özgün verinin ifade edebileceklerini kısıtlar ve ölçümleri fark edilmeden değiştirebilir. Bakırın fiberle değiştirilmesi de belirsizliği ortadan kaldırmaz: optik dönüşüm, uygulama protokolünün yorumunu değil, iletim ortamını değiştirir. Bağlantı kalitesi ve kodlama kuralları ayrı ayrı kontrol edilmelidir.
Kaçışlama veriyi değil, temsil biçimini değiştirir
Kaçışlama, sonraki baytı üzerinde anlaşılmış bir kurala göre yorumlama sinyali olarak düşünülebilir. Gönderici veri yükünü inceler ve korunan bayt değerlerini özel dizilerle değiştirir. Alıcı bu eşlemeyi tersine çevirir ve aynı özgün içeriği elde etmelidir.
RFC 1055 belgesinde açıklanan SLIP örneğinde, onaltılık C0 değeri END, DB ise ESC'dir. Veri yükü içindeki bir C0, DB DC'ye; veri yükü içindeki bir DB ise DB DD'ye dönüşür. Kaçışlanmamış bir C0, gerçek bitiş sınırını sağlar. Bu belirli değerler her seri protokole değil, bu örneğe aittir.
DB neden ayrıca kaçışlanır? Çünkü sonraki bayt için özel bir yorumlama başlatır. Özgün bir DB ayırt edilmeden gönderilirse, sonraki sıradan değer yanlışlıkla kaçış son eki olarak yorumlanabilir. Hem ayırıcının hem de kaçışı başlatan baytın korunması, yeni bir belirsizliğin oluşmasını önler.
Göndericiden alıcıya kısa bir örneği izleyin
Özgün veri yükünün 11 C0 22 DB 33 olduğunu varsayalım. İki özel değer, çerçevelenmiş akışa sıradan içerik olarak doğrudan yerleştirilemez. Kodlama sonucunda 11 DB DC 22 DB DD 33 elde edilir; gerçek END işaretçileri sonucu sınırlar, böylece alıcı kontrol rollerini geri yüklenen veriden ayırt edebilir.
Bu gösterimde C0, paketin hem önüne hem de arkasına yerleştirilir. RFC 1055, birikmiş gürültüyü temizlemenin bir yolu olarak başlangıçta bir END gönderilmesini ele alır; ardışık işaretçilerden oluşan sıfır uzunluklu sonuç, normal bir IP paketi olarak teslim edilmemelidir. Diğer protokoller her iki uçta mutlaka aynı işaretçileri kullanmaz.
Kod çözme işleminden sonra, veri yükündeki C0 ve DB yeniden sıradan veri olur. Ayırıcıların kendileri teslim edilen içeriğin parçası değildir. Kodlama, hat üzerindeki bayt sayısını artırabilir. Seri sunucu sayaçları, yakalamalar ve uygulama uzunlukları farklı katmanlarda ölçüldüğünde farklılık gösterebilir; bu durum veri kaybını kanıtlamaz.
Alıcı mevcut durumunu korumalıdır
Ayrıştırıcı her baytı her zaman tek başına değerlendiremez. En azından normal okuma durumuyla, kaçışı başlatan bayttan sonra bir son ek bekleme durumunu ayırt etmelidir. Normal durumda END paket sınırını işaretler; DB ise hemen özgün veri olarak DB üretmek yerine durumu son ek beklemeye geçirir.
Bekleme durumunda alıcı, üzerinde anlaşılmış eşlemeyi uygular ve normal duruma döner. İki bayt arasındaki ilişki ayrıştırıcının durumuyla korunur; baytların aynı yazılım okuma işleminde gelmesi gerekmez. Bir okuma DB ile biter ve sonraki DC ile başlarsa, alıcı durumunu korumalı ve dönüşümü tamamlamalıdır.
Gerçek bir uygulama ayrıca geçersiz son ekler, arabellek sınırları, boş paketler ve kesintiler için kurallara ihtiyaç duyar. Bu makale tek bir evrensel hata stratejisi dayatmaz. Yazılım her ağ okumasında ayrıştırma durumunu sıfırlarsa veya her okumanın bir mesaj olduğunu varsayarsa, taşıma katmanı tüm baytları iletmiş olsa bile çerçeveleme başarısız olabilir.
Bir sınır, hata denetimi veya güvenlik garantisi değildir
Kaçışlama, temsil belirsizliğini giderir. Kendiliğinden hata algılama, yeniden iletim, kimlik doğrulama veya şifreleme eklemez. Bir akışı paketlere ayırmak, her paketin doğru olduğunu veya göndericisinin güvenilir olduğunu kanıtlamaz. SLIP'in kendisi sınırlı hizmetler sunar ve genel bir endüstriyel kontrol güvenlik protokolü olarak ele alınmamalıdır.
Farklı protokoller, denetimleri ve kaçışlamayı farklı aşamalarda da uygulayabilir. PPP'nin HDLC benzeri çerçevelemesinin kendine özgü bayrak, şeffaflık ve çerçeve denetimi kuralları vardır; bu ayrıntılar SLIP ile aynı değildir. İşaretçi değerlerinin, kaçış son eklerinin veya denetim aşamalarının karıştırılması, her iki taraf da bayt alırken hiçbirinin bir paketi kabul etmemesine yol açabilir.
Özgün uygulama verisinin, kodlamanın, fiziksel veya ağ üzerinden taşımanın, kod çözmenin ve uygulama doğrulamasının nerede yer aldığını belirleyin. Hataları araştırırken beklenen içerikle karşılaştırma yapmadan önce gözlem katmanını belirleyin. Kodlanmış trafiğin kodu çözülmüş uygulama alanlarıyla doğrudan bayt bayt karşılaştırılması, gerçekte var olmayan bir arıza izlenimi yaratabilir.
Kuralların uyumunu tekrarlanabilir küçük örneklerle kontrol edin
Cihaz ve protokol belgeleriyle başlayın. Sürümleri, arayüz ayarlarını, paketlemeyi ve yakalama noktalarını kaydedin. Sıradan verileri, bitiş değerini içeren verileri, kaçış değerini içeren verileri ve ardışık özel değerleri test edin. Hem kodlanmış hem de kodu çözülmüş biçimleri kontrol edin. Bunlar açıklayıcı yöntemlerdir; belirli bir ürünün ölçüldüğü iddiası değildir.
Ardından, uygulamanın bunları ele alması gereken durumlarda bölünmüş okumaları, birleştirilmiş okumaları ve kesilen bağlantıları test edin. Yetkili bir ortamda zararsız veriler kullanın; örnek baytları canlı üretim komutları olarak kullanmayın. Uç noktalar farklı protokoller kullanıyorsa, baud hızlarını tekrar tekrar değiştirmeden önce dönüşümü kimin yaptığını belirleyin.
Katmanları unutmayın: UART karakterleri belirler, çerçeveleme kuralı mesajları belirler ve kaçışlama, veri yükündeki özel değerlerin kontrol işaretçileriyle karıştırılmasını önler. Bunları birbirinden ayırmak, bir port bayt alabilirken uygulamanın neden hâlâ tam bir mesajı yeniden oluşturamadığını açıklar.
Birincil kaynaklar
RFC 1055: SLIP, Haziran 1988, bir İnternet standardı değildir; RFC 1662: HDLC Benzeri Çerçevelemede PPP, Temmuz 1994. Ürün bağlamı: FCT-1100-F1S1 seri cihaz sunucusu; bu, ürünün SLIP kullandığı iddiası değildir.
Çince teknik makaleden çevrilmiştir: Çince özgün makaleyi okuyun.
Sık sorulan uygulama soruları
Seri karakterlerin alınması bir paketi kendiliğinden belirler mi?
Hayır. UART karakter alımı ve uygulama çerçevelemesi ayrı işlemlerdir; her iki uç noktanın da aynı çerçeveleme kurallarını kullanması gerekir.
SLIP, veri yükündeki C0 ve DB değerlerini nasıl kaçışlar?
Veri yükündeki C0, DB DC'ye; veri yükündeki DB ise DB DD'ye dönüşür; kaçışlanmamış END bir sınırı belirtir. Diğer protokoller farklı kurallar kullanabilir.
Bayt kaçışlama, bütünlük denetimlerinin veya şifrelemenin yerini alır mı?
Hayır. Kontrol işaretçileri ile veri yükü değerleri arasındaki belirsizliği giderir; kendiliğinden hata algılama, yeniden iletim, kimlik doğrulama veya şifreleme sağlamaz.
Kapsam ve ek okumalar
Genel bir SLIP çerçeveleme örneğidir; belirli bir ürün veya ölçülmüş veriler hakkında bir iddia değildir.
TCP yarı kapatma ve seri yanıtlar · RS485 birim yükleri ve sürücü bütçesi
