Mobil cihazlar ile Exchange server arasında bir senaryo


Asagidaki makalede Microsoft Exchange ile mobile cihazlar arasindaki iletisimde bir senaryoyu resmetmeye ve iki parametreyi tanitmaya çalistim. Umarim birilerinin isine yarar. Tanitmaya çalisacagimiz iki parametre web.config dosyasinda yer alan asagidaki parametreler.

 

 <add key="MinHeartbeatInterval" value="60">
 </add>
 <add key="MaxHeartbeatInterval" value="3540">
 </add>

 

Exchange ActiveSync (EAS) birçok mobile cihazin Exchange ile iletisiminde kullandigi ve 2005 yilinda özellikleri yeniden belirlenmis ve Exchange 2003 ile kullanima sunulmus uygulamanin adidir.  Bu uygulama AirSync adindaki protokolü ile çalisir. Bu protokol ile yapilan iletisimde session Exchange e ulasmadan önce Exchange CAS (Client Access Server) sunuculardaki Microsoft-Server-ActiveSync IIS virtual directory 'sine ve MSExchangeSyncAppPool uygulamasina ulasir. Bu asamada öncelikle authentication gerçeklestirilir (BASIC – clear text – güvenlik nedeniyle HTTPS zorunlu olmali). Proxying islemi ile session MBX (mailbox) sunucusuna transfer edilir ve bu asamada HBI's (HeartBeatIntervals) ve diger kurallar uygulanmaya baslanilir. Dikkat edilmesi gereken noktalardan biri de CAS ile MBX arasinda var olan Proxy Handler timeout süresidir (varsayilan olarak 1 saat). Bu uygulama virtual directory üzerinden bir kisim konfigürasyonunu belirler. Bahsini edecegim konfigürasyon web.config dosyasinda tutulmaktadir (2010 da CAS 2013 te MBX sunucuda). Varsayilan yeri; ..\program files\Microsoft\exchange server\Vxx\clientaccess\sync tir.

 

 

MinHeartbeatInterval ve MaxHeartbeatInterval degerleri cihazin sunucu ile arasindaki session'i açik tutmak için belirleyecegi min ve max süreleri belirlemek için kullanilir.. Bu süreler web.config file içerisinde yer alir ve varsayilan degerleri 60 ve 3540 tir.

 

Senaryo üzerinden parametrelerin etkisi;

 

1-  Cihaz kendisini Exchange 'e ilk register ettiginde 15 dakikalik (15*60 = 900 saniye) interval belirler. Su anlama gelir; eger 15 dakika içinde bir mail gelirse anlik olarak mail geldiginde Exchange cihaza mail var kendini sync et diye bir notification gönderecek fakat 15 dakika boyunca hiçbir aktivite olmazsa sunucu cihaza 15. dakikada HTTP 200 gönderecek (biz buna AirSync protokolünde PING diyoruz). Bunun amaci cihaz ile sunucu arasi baglantiyi açik tutmak böylece hangi cihazin hangi ip ve porttan iletisim kurabilecegini bilebilmektir. Eger session 'i açik tutmazsak Exchange -örnegin; Evren adli kullanicinin- cihazinin hangi porttan dinledigini bilemez ve tabi gelen mail ile ilgili notification 'i nereye bildirecegini de bilemez. Bu durumda Direct Push çalismaz hale gelir.

 

2-  Diyelim ki, her sey yolunda giderken cihazin Exchange ile iletisimi kayboldu… sonra da düzeldi (aradaki hat koptu firewall resetlendi vs), bu durumdan cihazin haberi yok (cihaz network 'e bagli olarak bir baglanti kaybina ugramadi ip'si ayni vs). Cihaz 15 dakika dolana kadar bekler ve 15. dakikada kendisine exchange 'ten HTTP 200 gelmeyince (çünkü birinci adimda açilmis session kapanmis durumda) cihaz yeni bir session açmak üzere Exchange ulasir ancak bu kez kendisine yeni bir Interval belirler yeni interval 8 dakikadir (%50 indirim yapar).

 

a-  8. Dakikada HTTP 200 geldi ve iletsim devam etti ise bir sorun olmadan o durumda cihaz yeni bir periyod belirler ve süreyi %50 arttirir (by design). Bu böylece devam eder ta ki.. MaxHeartbeatInterval’a kadar. Exchange ile cihaz arasi iletisimin 59 dakika açik kalabilmesi için öndeki tüm firewall'larda da timeout 1 sat civarinda tutulmus olmali. Birçok firewall bu süreyi yüksek görmekte memory kullanimini optimize etmek için 15 yada 30 dakika civarinda tutmaktadir. Timeout degeri TCP protokolü için özellikle HTTPs için geçerlidir.

 

b-  Eger 8. Dakikada yine HTTP 200 gelmezse bu durumda bir sonraki iletisimde cihaz yine %50 indirim yapar ve süreyi 4 dakikaya indirir.. Bu böylece devam eder ta ki.. MinHeartbeatInterval’a kadar. Bu süre varsayilan olarak 1 dakikadir.


Süreyi düsürmekten amaç cihazin iyi olmayan bir networke sahip oldugunu varsayarak max etkinlikte iletisim saglamaktir. (4 çekmeyen birçok yerde — ki birçok servis saglayici tersini iddia ediyor — benim bu blog'u yazdigim yerde 3G/Edge çekmiyor bazen baglanti bir kademeye düsüyor, yoo sakin uzaklarda oldugumu düsünmeyin Istanbul'dayim, bodrum katinda da degilim bu arada) Tersi de dogrudur yani süre %50 arttirilabilir de artirmaktaki amaç ise gereksiz trafigi azaltmak mobile maliyetleri düsürmektir.


Umarim yeterince açiklayici olmustur. Elbette çok daha fazlasi TechNet makalelerimiz ve degisik bloglar da mevcut.


Saygilarimla…


Kutbettin Ekici

Comments (1)

  1. Recep YUKSEL says:

    Elinize sağlık. Çok teşekkürler.

Skip to main content