Ana içeriğe atla

Web Servisi 3G Bağlantısında Retransmition Sorunu

Bu yazımızda istemci-sunucu arasında web servisi ve 3G iletişiminde gönderilen/alınan veri miktarlarında yaşanılan problemli bir senaryodan bahsedilecektir.
Problemli Senaryo Tanıtımı ve Deneyler
Aşağıdaki şekilde “Application Server” olarak adlandırılan sunucu üzerinde örnek bir web servisi bulunmaktadır. PDA istemci el terminali de 3G ile internete bağlanıp, web servisine erişerek bir dosya istemektedir. İstenilen dosya bayt dizesi olarak network üzerinden el terminaline gönderilmektedir.
image
Bu senaryoda alınan verinin boyutu 250 KB olmasına rağmen, network izleme araçlarıyla bakıldığında 1,25 MB civarında veri alış-verişi olduğu gözlenmektedir. Yani indirilen verinin 5 katı gibi bir veri boyutu oluşmaktadır. 3G sağlayıcılar, ücretlerini veri alış veriş miktarına göre belirlemektedir. Gerçek verinin 5 katı boyutunda veri alış verişi yapmak, doğal olarak fazla maliyet demektir. Problemin neden kaynaklandığını anlamak için senaryo aşağıdaki gibi farklılaştırılmıştır.
image
“NOTEBOOK” istemcisi normal ADSL bağlantı üzerinden ilgili web servisine bağlanıp aynı veriyi almaktadır. Hem indirilen veri hem de network üzerinden aktarılan verinin boyutu 250 KB olarak gözlenmiştir. Dolayısıyla bu senaryoda problem olmadığı görülmüştür.

5 kat farkın nereden oluştuğunu anlamak için network kartı üzerinden gelen giden paketleri tekrar izlenmeye başlanmıştır. Bunun için Microsoft’un bir ürünü olan Network Monitoring 3.3 programı kullanılmıştır. Yukarıdaki senaryolarda network monitoring aracı ile gidip gelen veriler izlenildiğinde, 244 KB büyüklüğündeki veri ADSL hattımızda 244KB ve 300 pakete ayrılarak indirilmesine rağmen 3G modem ile 1500 pakete ayrılarak 1,22 MB olarak indirilmektedir.
Aradaki farklara bakıldığında, 3G modem ile indirilen paketlerde “retransmit” attribute’ü ile belirtilmiş paketler görülmektedir. Bu durum aynı paketlerin birden fazla gönderilmesi anlamına gelmektedir. Genelde yeniden gönderilme işlemi, paketlerde bozulmalar olduğu zaman gerçekleşebilir.
244 KB * 5 = 1220 KB = 1,22 MB
Çözümler
Bu sorunların network altyapılarından kaynaklanma olasılığı yüksektir. Dolayısıyla çözüm sürecinde, öncelikle network altyapısına bakılmalıdır. Örnek senaryoda yaşanılan sorunun, network altyapısında kullanılan 4 adet fiziksel LAN kartlarının arasında oluşan uyumsuzluktan kaynaklandığı tespit edilmiştir. Gelen paket 1 network kartına girdikten sonra aynı karttan dönmesi gerekirken diğer 3 kartı da denemekte ve esas MAC adresini bulunca transfer başlamaktadır. Çözüm için LAN kartlarının sayısı düşürülmüş ve 3G ile aynı veri ADSL deki gibi retransmit olmadan indirilebilmiştir.
Eğer sorun bu şekilde çözülemiyorsa aşağıdaki çözüm denenebilir.
Eski SPI güvenlik duvarı olan NAT router’lar kullanılan sistemlerde, router arkasındaki sunucu üzerindeki “tcp auto-tuning” parametresinin değerine bakılmalıdır. Bu değer default olarak “normal”’dir. “Normal” olması durumunda, paket kayıplarına ve düşük hızlara sebep olabilmektedir. Auoto-tuning değerini değiştirerek bu sorun çözülebilir.
Auto-tuning parametresi şu değerleri alabilir:
  • disabled: Sabirt bir değer verilir. Maksimum 64KB olabilir.
  • highlyrestricted: default değerin ötesinde, aşırı bir şekilde büyüyerek artmasına olanak sağlar.
  • restricted: default değerin ötesinde sınırlı artmasını sağlar.
  • normal: default değerin koşullara uygun bir şekilde artmasını sağlar.
  • experimental: En uç senaryolara göre artış sağlar. Araştırma amaçlı kullanılabilir. Önerilmeyen bir değerdir.
Eğer bu tür routerlar ile sorun yaşanıyor ise, server üzerindeki auto-tuning parametresi değeri "restricted", " highlyrestricted" veya "disabled" duruma alınması sorunu giderebilecektir.Bu parametrenin değeri aşağıdaki komut ile değiştirilebilir.
netsh int tcp set global autotuninglevel=disabled
Armağan DÖKER, Ali KALFAOĞLU, Deniz KILINÇ

Yorumlar

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara