Dün VPN'e bağlanmaya çalıştığımda Error 800 hatasıyla karşılaştım. Hata şu idi:
"The remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPsec negotiation might not be configured properly."
Tek bir yolu var diyemem. Birçok sebepten olabilir. Ama benim işime yarayan çözüm şu şekilde: VPN'nin tunnel type'ı varsayılan olarak "Automatic" idi. Ben ise VPN tunnel type'ı elle seçmek istedim ama hangisi olduğunu bilmiyordum. L2TP tunnel type'ı seçince, başarılı bir şekilde VPN bağlantımı gerçekleştirdim. Sizinki PPTP de olabilir örneğin... Herkesinkinin L2TP olacak diye bir kaide yok. Püf nokta tunnel type idi.. (VPN bağlantınıza sağ tıklayıp, özelliklere girip tunnel type'ı değiştirebilirsiniz)
Görüşmek üzere..
27 Mart 2011 Pazar
22 Mart 2011 Salı
SQL Server'da Yetkilendirme:Grant,Deny,Revoke
Merhaba arkadaşlar,
Bugün sizlerle SQL Server'da yetkilendirme konusuna değineceğiz. Konu içerisinde kullanmak üzere bir login ve user tanımlayarak giriş yapalım.
create login gurkan with password='forzabesiktas'
komutuyla forzabesiktas şifresine sahip, gurkan adında bir kullanıcı oluşturmuş olduk. Şimdi bu login üzerinden bir kullanıcı yaratalım ve asıl konumuza başlayalım:
create user gurkan for login gurkan
User oluşturmuş olduk (Login ile user name aynı isimde.)
GRANT: Yetki vermek için kullanılır.
Genel yapısı şöyledir:
grant (all | izinler)
on (izneTabiTutulanlar)
to (izinVerilenler)
Hemen yaratığımız kullanıcı üzerinden örnekleyelim:
grant create table to gurkan --bu ifade ile gurkan adli kullaniciya tablo yaratma yetkisi vermis olduk
İsterseniz aynı kullanıcımıza tabloya eleman ekleme, silme ve güncelleme yetkileri verelim:
grant insert,update,delete to gurkan
Şimdi isterseniz herhangi bir tablo üzerinden select çekebilme yetkisi verelim. Ben Northwind kullandım, siz istediğiniz db ve tabloyu kullanabilirsiniz.
grant select on region to gurkan--bu ifade ile gurkan adli kullanici, region tablosundan select cekebilir.
WITH GRANT OPTION: Dereceli yetkilendirme işleminde kullanılır. Nedir bu peki? İzin verdiğiniz kullanıcının da izin verebilme yetisi kazanmasıdır. Yani siz bir kullanıcıya herhangi bir yetki verdiniz. O kullanıcı da, sizin ona verdiğiniz yetkilerin aynısını, başka bir kullanıcıya verebilir.
grant select,insert on region to gurkan
with grant option
ifadesi ile biz, gurkan adlı kullanıcıya region tablosu üzerinde select ve insert hakkı veriyoruz. Ama with grant option ifadesinden ötürü, gurkan kullanıcısı da, başkasına da bu hakkı verebilir. Fazla zaten veremez, kendisi ne kadar hak aldıysa, o kadar..
DENY: Grant ifadesinin tam tersidir. Yetkileri engeller; eriştirmez.Genel yapısı şöyledir:
deny (all | izinler)
to (izinVerilenler)
deny create table to gurkan--bu ifade ile gurkan kullanicisina tablo yaratmayi yasakladik
deny insert,select on products to gurkan--bu ifade ile gurkan kullanicisinin products tablosuna insert ve select yapmasini engelledik
REVOKE: Grant ile oynadığınız hakları eski haline döndürmek için kullanabilirsiniz bu ifadeyi. Genel yapısı şöyledir:
revoke (all | izinler)
to/from (izinVerilenler)
revoke all on region to gurkan--bu ifade ile gurkan kullanicisina verilen tum yetkiler kaldirilir
Deny neden var peki diyeceksiniz.. Şöyle anlatmaya çalışayım, deny ile bir kullanıcı hiçbir şekilde yasakladığınız şeyleri yapamaz. Ancak revoke dediğinizde, siz sadece yaptığınız işi geri almış oluyorsunuz ve sadece mevcut rol üzerinde işlem yapıyorsunuz. Aynı kullanıcı farklı rollerde bu işi yapmayı sürdürebilir.
Yukarıda hatırlarsanız with grant option ile yetki verdiğimiz kullanıcılar da aynı yetkileri başka kullanıcılara verebiliyordu. Şimdi biz az önceki revoke örneğimizde, gurkan adli kullanicinin yetkisini kaldirdik. Peki onun yetkilendirdikleri ne olacak? Tam da bu noktada "Cascade" ifadesi devreye giriyor. Cascade ile bu da kaldırılır. Örnekleyelim hemen:
revoke all to gurkan cascade--bu ifade ile gurkan kullanicisinin yetkilendirdigi diger kullanicilarin da yetkilerini kaldirmis olduk
Görüşmek üzere..
Bugün sizlerle SQL Server'da yetkilendirme konusuna değineceğiz. Konu içerisinde kullanmak üzere bir login ve user tanımlayarak giriş yapalım.
create login gurkan with password='forzabesiktas'
komutuyla forzabesiktas şifresine sahip, gurkan adında bir kullanıcı oluşturmuş olduk. Şimdi bu login üzerinden bir kullanıcı yaratalım ve asıl konumuza başlayalım:
create user gurkan for login gurkan
User oluşturmuş olduk (Login ile user name aynı isimde.)
GRANT: Yetki vermek için kullanılır.
Genel yapısı şöyledir:
grant (all | izinler)
on (izneTabiTutulanlar)
to (izinVerilenler)
Hemen yaratığımız kullanıcı üzerinden örnekleyelim:
grant create table to gurkan --bu ifade ile gurkan adli kullaniciya tablo yaratma yetkisi vermis olduk
İsterseniz aynı kullanıcımıza tabloya eleman ekleme, silme ve güncelleme yetkileri verelim:
grant insert,update,delete to gurkan
Şimdi isterseniz herhangi bir tablo üzerinden select çekebilme yetkisi verelim. Ben Northwind kullandım, siz istediğiniz db ve tabloyu kullanabilirsiniz.
grant select on region to gurkan--bu ifade ile gurkan adli kullanici, region tablosundan select cekebilir.
WITH GRANT OPTION: Dereceli yetkilendirme işleminde kullanılır. Nedir bu peki? İzin verdiğiniz kullanıcının da izin verebilme yetisi kazanmasıdır. Yani siz bir kullanıcıya herhangi bir yetki verdiniz. O kullanıcı da, sizin ona verdiğiniz yetkilerin aynısını, başka bir kullanıcıya verebilir.
grant select,insert on region to gurkan
with grant option
ifadesi ile biz, gurkan adlı kullanıcıya region tablosu üzerinde select ve insert hakkı veriyoruz. Ama with grant option ifadesinden ötürü, gurkan kullanıcısı da, başkasına da bu hakkı verebilir. Fazla zaten veremez, kendisi ne kadar hak aldıysa, o kadar..
DENY: Grant ifadesinin tam tersidir. Yetkileri engeller; eriştirmez.Genel yapısı şöyledir:
deny (all | izinler)
to (izinVerilenler)
deny create table to gurkan--bu ifade ile gurkan kullanicisina tablo yaratmayi yasakladik
deny insert,select on products to gurkan--bu ifade ile gurkan kullanicisinin products tablosuna insert ve select yapmasini engelledik
REVOKE: Grant ile oynadığınız hakları eski haline döndürmek için kullanabilirsiniz bu ifadeyi. Genel yapısı şöyledir:
revoke (all | izinler)
to/from (izinVerilenler)
revoke all on region to gurkan--bu ifade ile gurkan kullanicisina verilen tum yetkiler kaldirilir
Deny neden var peki diyeceksiniz.. Şöyle anlatmaya çalışayım, deny ile bir kullanıcı hiçbir şekilde yasakladığınız şeyleri yapamaz. Ancak revoke dediğinizde, siz sadece yaptığınız işi geri almış oluyorsunuz ve sadece mevcut rol üzerinde işlem yapıyorsunuz. Aynı kullanıcı farklı rollerde bu işi yapmayı sürdürebilir.
Yukarıda hatırlarsanız with grant option ile yetki verdiğimiz kullanıcılar da aynı yetkileri başka kullanıcılara verebiliyordu. Şimdi biz az önceki revoke örneğimizde, gurkan adli kullanicinin yetkisini kaldirdik. Peki onun yetkilendirdikleri ne olacak? Tam da bu noktada "Cascade" ifadesi devreye giriyor. Cascade ile bu da kaldırılır. Örnekleyelim hemen:
revoke all to gurkan cascade--bu ifade ile gurkan kullanicisinin yetkilendirdigi diger kullanicilarin da yetkilerini kaldirmis olduk
Görüşmek üzere..
21 Mart 2011 Pazartesi
Internet Explorer 9
Merhaba arkadaşlar,
Kısa bir haber paylaşmak istiyorum sizlerle. Malumunuz tam 1 hafta önce IE9 kullanıma hazır hale geldi ve indirmeniz için yerini aldı. http://www.beautyoftheweb.com adresine girip, sağ taraftaki "download" düğmesine basarak indirebilirsiniz. Ancak.. IE9 XP işletim sistemi kullananlar için yasak. :) Microsoft XP kullanımını bitirmek için önce sürücü güncellemelerini kaldırdı, şimdi de tarayıcı desteğini çekti. İlginç olan, Linux ortamıyla da uyumsuz imiş. Linux'ta bizzat test etmedim, haberlerde gördüm. XP çok eskidi, bu yüzden doğru bir hamle diyebilirsiniz. Kaldı ki haklısınız da. Ancak dünyadaki veriler gösteriyor ki hala dünya nüfusunun %40'ından fazlası Windows XP kullanıyor. Hal böyleyken bu kararı almak biraz riskli. Zaten ilk dakikadan golü de yemişler. Firefox 4, XP desteğiyle çıkıyor. Gerisini Microsoft düşünsün. :) Firefox 4 de aksilik çıkmazsa yarın görücüye çıkıyor. Haydi hayırlısı. :)
Ufak bir düzenleme: http://people.mozilla.com/~prouget/ie9/ie9_vs_fx4.html bağlantısına girin. Mozilla öyle veriler sunmuş ki, kan çıkacak. :D
Kısa bir haber paylaşmak istiyorum sizlerle. Malumunuz tam 1 hafta önce IE9 kullanıma hazır hale geldi ve indirmeniz için yerini aldı. http://www.beautyoftheweb.com adresine girip, sağ taraftaki "download" düğmesine basarak indirebilirsiniz. Ancak.. IE9 XP işletim sistemi kullananlar için yasak. :) Microsoft XP kullanımını bitirmek için önce sürücü güncellemelerini kaldırdı, şimdi de tarayıcı desteğini çekti. İlginç olan, Linux ortamıyla da uyumsuz imiş. Linux'ta bizzat test etmedim, haberlerde gördüm. XP çok eskidi, bu yüzden doğru bir hamle diyebilirsiniz. Kaldı ki haklısınız da. Ancak dünyadaki veriler gösteriyor ki hala dünya nüfusunun %40'ından fazlası Windows XP kullanıyor. Hal böyleyken bu kararı almak biraz riskli. Zaten ilk dakikadan golü de yemişler. Firefox 4, XP desteğiyle çıkıyor. Gerisini Microsoft düşünsün. :) Firefox 4 de aksilik çıkmazsa yarın görücüye çıkıyor. Haydi hayırlısı. :)
Ufak bir düzenleme: http://people.mozilla.com/~prouget/ie9/ie9_vs_fx4.html bağlantısına girin. Mozilla öyle veriler sunmuş ki, kan çıkacak. :D
20 Mart 2011 Pazar
Mario Balotelli
Videoyu kesinlikle sonuna kadar izleyin. Bu adamın neden beklenen patlamayı yapamadığının cevabı olsa gerek. :) Dinamo Kiev maçı öncesi, yeleğini giymeye çalışan Balotelli... :)
Şampiyonlar Şampiyonu Vakıfbank(VGSTT)
Az önce biten maçta Vakıfbank Güneş Sigorta Türk Telekom voleybol takımımız, Azerbaycan'ın Rabita Bakü takımını 3-0 (25-13, 25-20 ve 25-19) yenerek, Şampiyonlar Ligi Şampiyonu olmuş ve Avrupa'nın en büyük kupasını ülkemize kazandırmıştır. Hem de şampiyona boyunca oynadığı 12 maçın tamamını kazanarak bunu gerçekleştirmiştir.
Kendilerini tebrik ediyorum...
Kendilerini tebrik ediyorum...
19 Mart 2011 Cumartesi
Scheduling Algorithms vol.2
Tekrar merhaba herkese,
Zamanlama algoritmalarında kaldığımız yerden ediyoruz. Eğer bundan önceki yazıyı okumadan bu kayda yönlendiyseniz: http://gurkanalkan.blogspot.com/2011/03/scheduling-algorithms-zamanlama.html bağlantısına bir göz atın derim.
Round Robin Scheduling: Bu algoritmada tüm process'lere belli bir quantum süresi veriliyor. Eğer çalışan process'in quantum süresi dolduğunda hala çalışıyorsa, bloklanır ve listenin sonuna atılır; sıradaki process çalışmaya başlar. Bu algoritma tüm process'lerin aynı öncelikte olduğunu farz eder. Püf noktası ise quantum sürelerinin uzunluğudur. Çünkü bir process'ten başka bir process'e geçme işlemi de bayağı masraflı bir işlemdir. Eğer quantum süreleri kısa tutulursa, sürekli process'ler arasında geçişler olur ve bunun için de işlemci fazladan zaman ayırmış olur. Eğer quantum süresi bir uzun tutulursa, çalışan process için sorun yoktur belki ama bekleyen process'lere çok geç cevap verilmiş olur.
Priority Scheduling: Process'lere öncelik verir ve o önceliklere göre de çalıştırır. Önceliği yüksek olan çalışır haliyle. Ancak "priority"si, yani önceliği, yüksek olan process sürekli çalışır mı bu mantıkla? Eğer siz bir önlem almazsanız, çalışır. Bu yüzden şöyle bir yol izlenebilinir: her process'e belli bir quantum süresi verirsiniz. Quantum süresi dolan process'in de önceliğini düşürürsünüz. Örnek vereli hemen.
A:4 B:3 C:2 önceliklerine sahip olsun.
A process'inin quantum süresi dolunca, A'nın önceliği 3'e düşürülür. Ve B'nin arkasına geçer hemen. B çalışır, önceliği 2'ye düşer ve C process'inin arkasına geçer. Ardından A process(en son 3 olmuştu önceliği)'i çalışır ve önceliği 2'ye düşer, o da C ve B'nin arkasına yerleşir. Bu şekilde tüm process'ler çalıştırılmış olur. Tanenbaum ise her saat vuruşunda önceliği azaltma fikrini öne sürüyor ancak benim anlattığım yöntem daha makul görünüyor...
Guaranteed Scheduling: Process'leri schedule etmeden inceliyor bu algoritma; ne kadar quantum süresi vermiş ve o process bunun ne kadarını kullanmış vs. Verilen zamanın daha azını kullanmışsa, o process'in önceliği olur. Şöyle ki:
A:5 ms'de işini halledebiliyor.
B:10 ms'de işini halledebiliyor.
C:20 ms'de işini halledebiliyor.
Her birine 10 ms'lik quantum süresi atadığımızda: A'nın oranı 5/10=0,5 olur. Aynı hesapla B'nin oranı 1, C process'ininki de 2 olur. En kısa sürede A process'i işini halledeceğinden de öncelik onundur. Ne zamana kadar? Ta ki A process'i çok çalışıp da B process'inin oranına gelinceye dek...
Lottery Scheduling: Adından da belli olacağı üzere tamamen piyangonun size vurmasıyla alakalı. :) Her process'e bir bilet veriyor bu algoritma. Ve random olarak bir process'i seçiyorsunuz, kimin bileti çıkarsa artık.. Bir process istediği kadar bilete sahip olabilir ve ne kadar çok bileti olursa, şansı da o kadar yüksek olur. :) Bildiğiniz piyango olayı, ismi de o yüzden öyle. Örnek verelim hemen:
A-8 bilet
B-5 bilet
C-7 bilet
Random olarak bir bileti seçeceğiz ve bu bilet kimdeyse, o process çalışacak. A process'i en şanslısı çünkü 8 bileti var. Olay bu kadar basit. Random Number Generator mantığı lazım buraya ki daha adil ve düzgün bir dağıtım olabilsin process'ler arasında. Klasik kullanım yeri örneğini ben de vereyim: video server'lar. Saniyede kaç frame alacağına bakıp, process'lere o kadar bilet verirsiniz...
Fair-Share Scheduling: Bu algoritma process'ten ziyade kullancılarını göz önüne alır. O yüzden önce hangi kullanıcıda kaç process var olduğu belirlenmelidir. Örneğin birinci kullanıcının çok fazla process'i vardır, ikinci kullanıcının ise nispeten daha az... Bu durumda birinci kullanıcı daha fazla CPU zamanını kullanacaktır. İşte, yine adından da anlayacağınız, Fair-Share'den yana bu algoritma buna karşı çıkıyor ve diyor ki: madem iki kullanıcı var, CPU zamanını %50-%50 paylaştıralım.
Örnek verelim hemen. 1nci kullanıcının process'leri:A-B-C. 2nci kullanıcının processleri:D-E olsun.
Çalışma şekli şöyle olacaktır.
A-D-B-E-C-D-A-E-B-D-C-E........
Yani bir process ilk kullanıcıdan, bir process de ikinci kullanıcıdan gelir.
Three Level Scheduling: 3 aşamalı bir algoritmadır kendileri.
1.Admission Scheduler: Job'lar sisteme gelir ve kuyrukta bekletilir bu aşamada. Hangilerinin alınacağına karar verilir. Buna herhangi bir algoritma ile karar verilir.
2. Memory Scheduler: Hangi process'lerin memory'de kalacağı, hangilerinin diske yazılacağını belirleyen aşamadır.
3. CPU Scheduler: Yine herhangi bir algoritma kullanılarak, hangi process'in çalışacağına karar verilir.
Konumuz burada son buluyor. Sonra görüşürüz..
Zamanlama algoritmalarında kaldığımız yerden ediyoruz. Eğer bundan önceki yazıyı okumadan bu kayda yönlendiyseniz: http://gurkanalkan.blogspot.com/2011/03/scheduling-algorithms-zamanlama.html bağlantısına bir göz atın derim.
Round Robin Scheduling: Bu algoritmada tüm process'lere belli bir quantum süresi veriliyor. Eğer çalışan process'in quantum süresi dolduğunda hala çalışıyorsa, bloklanır ve listenin sonuna atılır; sıradaki process çalışmaya başlar. Bu algoritma tüm process'lerin aynı öncelikte olduğunu farz eder. Püf noktası ise quantum sürelerinin uzunluğudur. Çünkü bir process'ten başka bir process'e geçme işlemi de bayağı masraflı bir işlemdir. Eğer quantum süreleri kısa tutulursa, sürekli process'ler arasında geçişler olur ve bunun için de işlemci fazladan zaman ayırmış olur. Eğer quantum süresi bir uzun tutulursa, çalışan process için sorun yoktur belki ama bekleyen process'lere çok geç cevap verilmiş olur.
Priority Scheduling: Process'lere öncelik verir ve o önceliklere göre de çalıştırır. Önceliği yüksek olan çalışır haliyle. Ancak "priority"si, yani önceliği, yüksek olan process sürekli çalışır mı bu mantıkla? Eğer siz bir önlem almazsanız, çalışır. Bu yüzden şöyle bir yol izlenebilinir: her process'e belli bir quantum süresi verirsiniz. Quantum süresi dolan process'in de önceliğini düşürürsünüz. Örnek vereli hemen.
A:4 B:3 C:2 önceliklerine sahip olsun.
A process'inin quantum süresi dolunca, A'nın önceliği 3'e düşürülür. Ve B'nin arkasına geçer hemen. B çalışır, önceliği 2'ye düşer ve C process'inin arkasına geçer. Ardından A process(en son 3 olmuştu önceliği)'i çalışır ve önceliği 2'ye düşer, o da C ve B'nin arkasına yerleşir. Bu şekilde tüm process'ler çalıştırılmış olur. Tanenbaum ise her saat vuruşunda önceliği azaltma fikrini öne sürüyor ancak benim anlattığım yöntem daha makul görünüyor...
Guaranteed Scheduling: Process'leri schedule etmeden inceliyor bu algoritma; ne kadar quantum süresi vermiş ve o process bunun ne kadarını kullanmış vs. Verilen zamanın daha azını kullanmışsa, o process'in önceliği olur. Şöyle ki:
A:5 ms'de işini halledebiliyor.
B:10 ms'de işini halledebiliyor.
C:20 ms'de işini halledebiliyor.
Her birine 10 ms'lik quantum süresi atadığımızda: A'nın oranı 5/10=0,5 olur. Aynı hesapla B'nin oranı 1, C process'ininki de 2 olur. En kısa sürede A process'i işini halledeceğinden de öncelik onundur. Ne zamana kadar? Ta ki A process'i çok çalışıp da B process'inin oranına gelinceye dek...
Lottery Scheduling: Adından da belli olacağı üzere tamamen piyangonun size vurmasıyla alakalı. :) Her process'e bir bilet veriyor bu algoritma. Ve random olarak bir process'i seçiyorsunuz, kimin bileti çıkarsa artık.. Bir process istediği kadar bilete sahip olabilir ve ne kadar çok bileti olursa, şansı da o kadar yüksek olur. :) Bildiğiniz piyango olayı, ismi de o yüzden öyle. Örnek verelim hemen:
A-8 bilet
B-5 bilet
C-7 bilet
Random olarak bir bileti seçeceğiz ve bu bilet kimdeyse, o process çalışacak. A process'i en şanslısı çünkü 8 bileti var. Olay bu kadar basit. Random Number Generator mantığı lazım buraya ki daha adil ve düzgün bir dağıtım olabilsin process'ler arasında. Klasik kullanım yeri örneğini ben de vereyim: video server'lar. Saniyede kaç frame alacağına bakıp, process'lere o kadar bilet verirsiniz...
Fair-Share Scheduling: Bu algoritma process'ten ziyade kullancılarını göz önüne alır. O yüzden önce hangi kullanıcıda kaç process var olduğu belirlenmelidir. Örneğin birinci kullanıcının çok fazla process'i vardır, ikinci kullanıcının ise nispeten daha az... Bu durumda birinci kullanıcı daha fazla CPU zamanını kullanacaktır. İşte, yine adından da anlayacağınız, Fair-Share'den yana bu algoritma buna karşı çıkıyor ve diyor ki: madem iki kullanıcı var, CPU zamanını %50-%50 paylaştıralım.
Örnek verelim hemen. 1nci kullanıcının process'leri:A-B-C. 2nci kullanıcının processleri:D-E olsun.
Çalışma şekli şöyle olacaktır.
A-D-B-E-C-D-A-E-B-D-C-E........
Yani bir process ilk kullanıcıdan, bir process de ikinci kullanıcıdan gelir.
Three Level Scheduling: 3 aşamalı bir algoritmadır kendileri.
1.Admission Scheduler: Job'lar sisteme gelir ve kuyrukta bekletilir bu aşamada. Hangilerinin alınacağına karar verilir. Buna herhangi bir algoritma ile karar verilir.
2. Memory Scheduler: Hangi process'lerin memory'de kalacağı, hangilerinin diske yazılacağını belirleyen aşamadır.
3. CPU Scheduler: Yine herhangi bir algoritma kullanılarak, hangi process'in çalışacağına karar verilir.
Konumuz burada son buluyor. Sonra görüşürüz..
18 Mart 2011 Cuma
Scheduling Algorithms (Zamanlama Algoritmaları)
Merhaba arkadaşlar,
İşletim Sistemlerinden devam ediyoruz. Ama az önce, kelepçeleriyle ünlenmiş Kazım fenere gol attı. :) Bu notu ilettikten sonra konumuza başlayalım. Öncelikle scheduling, ya da naı diğer zamanlama, nedir? Scheduling, bekleyen process'lerden hangisinin çalışacağına karar veren mekanizmadır en basit tanımla. Bu kararı vermek için çeşitli algoritmalar tanımlanmış. Sırayla bu algoritmalara göz atacağız. Ama ondan önce iki kavramdan bahsedeyim. Preemptive ve Non-Preemptive.
Preemptive algoritmalarda, bir process seçilir ve belli bir süre çalışmasına müsaade edilir. Bu süre bitince de process askıya alınır ve başka process seçilir ve o çalışmaya başlar artık.
Non-Preemptive algoritmalarda ise yine bir process seçilir. Ancak o process kendi isteği ile sonlanana kadar çalışır. Zaten non-preemptive de kelime olarak kesintisiz demek. Kesintisiz bir şekilde process çalışıyor...
(Bu iki kavramı bana hatırlatan Tanenbaum'un Operating System kitabına atıfta bulunmalıyım)
Algoritmalara geçelim isterseniz...
First Come First Served: En kolay algoritmalardan birisi oluyor kendileri. Non-Preemptive bir algoritmadır. Process'ler hangi sırayla gelirse, o sırada çalışır. Non-Preemptive olduğu için de işini bitirene kadar da çalışır. Bu process'ler "kuyruk"ta tutulur. Gelen process kuyruğun sonuna geçer ve sırasını bekler. Çalışan process ise işi bitince kuyruğun sonuna atılır. Konuya yeni başladık, anlaşılması için bir örnek yapalım hemen.
A-B-C-D processleri olsun. Yazdıldıkları sırada da gelmiş olsunlar.
A:1 B:2 C:3 D:4 ms'de işini yapıyor olsun.
Önce A geldi. 1 ms'de işini halletti. Sistem 1 ms bekledi.
Sonra B geldi. A 1 ms'de işini yaparken B onu bekliyordu. Ardından 2 ms'de de kendi işini halletti. 1+2=3 ms de B process'i için gereken zaman...
Akabinde C geldi. A process'i işini yaparken 1 ms bekledi. Ardından 2 ms de B process'i işini yaparken bekledi. 3 ms'de de kendi işini halletti. 1+2+3=6 ms de C process'i için gereken zaman.
Son olarak D process'i geldi. A process'i işini yaparken 1 ms bekledi. 2 ms de B process'i işini yaparken bekledi. Ardından 3 ms de C process'i için bekledi. Kendisi de 4ms'de işini halletti. 1+2+3+4=10 ms
Her process için ortalama bekleme süresi=1+3+6+10/4=5 ms...
Shortest Job First: Bu algoritma da Non-Preemptive'dir. Süresi daha az olan process önce çalışır. Hangi process'in ne kadar çalışacağı da bilinmelidir bu yüzden, ki en büyük sorunu da budur. Bunu bildiğimizde, işini bitirmek için en fazla zamana ihtiyacı olan process kuyruğun en sonuna atılır. Kısa sürede bitirebilen process olduğu sürece, kuyruğun sonunda bekler, uzun sürede bitirecek olan process'ler... Aynı örneği bu algoritma için de yapalım hemen:
A-B-C-D processleri olsun. Bu algoritmada process'lerin geliş sırası önemsizdir.
A:4 B:2 C:1 D:3 ms'de işini yapıyor olsun. (Diğer sorudan farklı olarak süreleri değiştirdim, aman dikkat!!)
Sistem bakacak ve en kısa sürede işini C process'inin bitirebileceğini görecek(1 ms değeri en küçük değer çünkü). Önce C process'i işini yapacak. 1 ms sürede..
Ardından 2 ms ile B process'i işini yapar. Fazla uzatmayayım, akabinde 3 ms ile D process'i ve en son da 4 ms ile A process'i işini yapar bu algoritmaya göre.
Shortest Remaining Time Next: Bu algoritmada process'in geçmişiyle ilgilenmiyoruz. Process'in işini bir an önce bitirmesi esastır. Yani process'in işini bitirmesine ne kadar kalmış, o önemli. Yalnız bu algoritma Preemptive'dir. Yani belli bir süre verirsin process'e. O sürede yaptıysa ne ala; yoksa kuyruğun en sonuna şutlarız kendilerini. Yeni bir process geldiğinde kuyruğa, hemen hali hazırda çalışmasına izin verdiğimiz process ile karşılaştırırız. Eğer yeni process'in çalışmasını bitirmesi için gerek süre, çalışan process'inkinden daha az ise, çalışan process'i bloklarız ve yeni gelen process'i çalıştırırız. Eğer Non-Preemptive olsaydı, asla bloklayamazdık; çalışan process'in keyfini beklerdik. :)
Yazıma burada ara veriyorum. Okunurluğun düşmemesi önemli. Daha da önemlisi Forza'da gese-febe maçındaki muhtemel kırmızı kart sayısına dair iddialaştık, takip edeyim maçın ikinci yarısını. :)
Yarın görüşürüz..
İşletim Sistemlerinden devam ediyoruz. Ama az önce, kelepçeleriyle ünlenmiş Kazım fenere gol attı. :) Bu notu ilettikten sonra konumuza başlayalım. Öncelikle scheduling, ya da naı diğer zamanlama, nedir? Scheduling, bekleyen process'lerden hangisinin çalışacağına karar veren mekanizmadır en basit tanımla. Bu kararı vermek için çeşitli algoritmalar tanımlanmış. Sırayla bu algoritmalara göz atacağız. Ama ondan önce iki kavramdan bahsedeyim. Preemptive ve Non-Preemptive.
Preemptive algoritmalarda, bir process seçilir ve belli bir süre çalışmasına müsaade edilir. Bu süre bitince de process askıya alınır ve başka process seçilir ve o çalışmaya başlar artık.
Non-Preemptive algoritmalarda ise yine bir process seçilir. Ancak o process kendi isteği ile sonlanana kadar çalışır. Zaten non-preemptive de kelime olarak kesintisiz demek. Kesintisiz bir şekilde process çalışıyor...
(Bu iki kavramı bana hatırlatan Tanenbaum'un Operating System kitabına atıfta bulunmalıyım)
Algoritmalara geçelim isterseniz...
First Come First Served: En kolay algoritmalardan birisi oluyor kendileri. Non-Preemptive bir algoritmadır. Process'ler hangi sırayla gelirse, o sırada çalışır. Non-Preemptive olduğu için de işini bitirene kadar da çalışır. Bu process'ler "kuyruk"ta tutulur. Gelen process kuyruğun sonuna geçer ve sırasını bekler. Çalışan process ise işi bitince kuyruğun sonuna atılır. Konuya yeni başladık, anlaşılması için bir örnek yapalım hemen.
A-B-C-D processleri olsun. Yazdıldıkları sırada da gelmiş olsunlar.
A:1 B:2 C:3 D:4 ms'de işini yapıyor olsun.
Önce A geldi. 1 ms'de işini halletti. Sistem 1 ms bekledi.
Sonra B geldi. A 1 ms'de işini yaparken B onu bekliyordu. Ardından 2 ms'de de kendi işini halletti. 1+2=3 ms de B process'i için gereken zaman...
Akabinde C geldi. A process'i işini yaparken 1 ms bekledi. Ardından 2 ms de B process'i işini yaparken bekledi. 3 ms'de de kendi işini halletti. 1+2+3=6 ms de C process'i için gereken zaman.
Son olarak D process'i geldi. A process'i işini yaparken 1 ms bekledi. 2 ms de B process'i işini yaparken bekledi. Ardından 3 ms de C process'i için bekledi. Kendisi de 4ms'de işini halletti. 1+2+3+4=10 ms
Her process için ortalama bekleme süresi=1+3+6+10/4=5 ms...
Shortest Job First: Bu algoritma da Non-Preemptive'dir. Süresi daha az olan process önce çalışır. Hangi process'in ne kadar çalışacağı da bilinmelidir bu yüzden, ki en büyük sorunu da budur. Bunu bildiğimizde, işini bitirmek için en fazla zamana ihtiyacı olan process kuyruğun en sonuna atılır. Kısa sürede bitirebilen process olduğu sürece, kuyruğun sonunda bekler, uzun sürede bitirecek olan process'ler... Aynı örneği bu algoritma için de yapalım hemen:
A-B-C-D processleri olsun. Bu algoritmada process'lerin geliş sırası önemsizdir.
A:4 B:2 C:1 D:3 ms'de işini yapıyor olsun. (Diğer sorudan farklı olarak süreleri değiştirdim, aman dikkat!!)
Sistem bakacak ve en kısa sürede işini C process'inin bitirebileceğini görecek(1 ms değeri en küçük değer çünkü). Önce C process'i işini yapacak. 1 ms sürede..
Ardından 2 ms ile B process'i işini yapar. Fazla uzatmayayım, akabinde 3 ms ile D process'i ve en son da 4 ms ile A process'i işini yapar bu algoritmaya göre.
Shortest Remaining Time Next: Bu algoritmada process'in geçmişiyle ilgilenmiyoruz. Process'in işini bir an önce bitirmesi esastır. Yani process'in işini bitirmesine ne kadar kalmış, o önemli. Yalnız bu algoritma Preemptive'dir. Yani belli bir süre verirsin process'e. O sürede yaptıysa ne ala; yoksa kuyruğun en sonuna şutlarız kendilerini. Yeni bir process geldiğinde kuyruğa, hemen hali hazırda çalışmasına izin verdiğimiz process ile karşılaştırırız. Eğer yeni process'in çalışmasını bitirmesi için gerek süre, çalışan process'inkinden daha az ise, çalışan process'i bloklarız ve yeni gelen process'i çalıştırırız. Eğer Non-Preemptive olsaydı, asla bloklayamazdık; çalışan process'in keyfini beklerdik. :)
Yazıma burada ara veriyorum. Okunurluğun düşmemesi önemli. Daha da önemlisi Forza'da gese-febe maçındaki muhtemel kırmızı kart sayısına dair iddialaştık, takip edeyim maçın ikinci yarısını. :)
Yarın görüşürüz..
18 Mart Çanakkale Deniz Zaferi
Bugün, her ne kadar hissettirilmesek de, 18 Mart 1915'in, başka bir deyişle Çanakkale Deniz Zaferinin yıldönümü.
Varlığımızı borçlu olduğumuz nice isimsiz kahraman... Artık tek ses medyada haberlere bile konu edilemiyorsunuz maalesef. Edilseniz bile sadece klasik bir fon müziği, bir şiir ve 30 sn sonra magazinsel siyaset... Öyle bir dönemdeyiz ki, yaptığınız fedakarlıklar, insanüstü gayretler mistik güçlerle, hurafelerle küçümseniyor. Bir milletin doğumgünü niteliğindeki zaferinizin amaçları, sonuçları anlatılmıyor. Sadece elde kalmış birkaç kağıt parçasından basmakalıp satırlar... Sürekli dönen arşivdeki videolar... Hepsi bu. Bazı soysuzlar böyle bir savaş olmadığını bile iddia edebiliyor. Bazıları ise sizlere küfrederek Avrupa'dan ödüller kazanıyor. Torunlarınız olarak o gün geldiğinde yüzünüze nasıl bakacağız bilemiyoruz...
Mekanınız cennet olsun...
Varlığımızı borçlu olduğumuz nice isimsiz kahraman... Artık tek ses medyada haberlere bile konu edilemiyorsunuz maalesef. Edilseniz bile sadece klasik bir fon müziği, bir şiir ve 30 sn sonra magazinsel siyaset... Öyle bir dönemdeyiz ki, yaptığınız fedakarlıklar, insanüstü gayretler mistik güçlerle, hurafelerle küçümseniyor. Bir milletin doğumgünü niteliğindeki zaferinizin amaçları, sonuçları anlatılmıyor. Sadece elde kalmış birkaç kağıt parçasından basmakalıp satırlar... Sürekli dönen arşivdeki videolar... Hepsi bu. Bazı soysuzlar böyle bir savaş olmadığını bile iddia edebiliyor. Bazıları ise sizlere küfrederek Avrupa'dan ödüller kazanıyor. Torunlarınız olarak o gün geldiğinde yüzünüze nasıl bakacağız bilemiyoruz...
Mekanınız cennet olsun...
15 Mart 2011 Salı
ManBearPig :)
Uzun zamandır eğlenceli bir kayıt girmemiştim. Neyseki Al Gore ülkemize geldi ve bizlere güzel bir malzeme verdi. :)
Tabi ki ondan bahsediyorum.. Yeryüzünün en tehlikeli yaratığından: Manbearpig.. :)
Kimilerine göre yarı ayı, yarı domuz, yarı insan...
Kimilerine göre yarı domuz, yarı insan, yarı ayı...
Ama o yarı insan, yarı ayı, yarı domuz... :)
Şimdi ne saçmalıyor bu gene diyeceksiniz. :) South Park izleyicilerine özel olsun bu kayıt. :) Dizide Al Gore'un dikkat çekmek ve toplum nezdinde yer edinmek için yaptıklarıyla ve çektirdiği "an inconvenient truth" adlı filmle dalga geçiliyor.
Ayrıca bir vatandaş kendisine fena çarpmış: http://current.com/entertainment/comedy/89504417_current-presents-digg-dialogg-al-gore-on-manbearpig.htm :)
Sosyal mesajımızı Kyle'ın elinden vererek yazımı sonlandırıyorum. Görüşmek üzere.. :)
Tabi ki ondan bahsediyorum.. Yeryüzünün en tehlikeli yaratığından: Manbearpig.. :)
Kimilerine göre yarı ayı, yarı domuz, yarı insan...
Kimilerine göre yarı domuz, yarı insan, yarı ayı...
Ama o yarı insan, yarı ayı, yarı domuz... :)
Şimdi ne saçmalıyor bu gene diyeceksiniz. :) South Park izleyicilerine özel olsun bu kayıt. :) Dizide Al Gore'un dikkat çekmek ve toplum nezdinde yer edinmek için yaptıklarıyla ve çektirdiği "an inconvenient truth" adlı filmle dalga geçiliyor.
Ayrıca bir vatandaş kendisine fena çarpmış: http://current.com/entertainment/comedy/89504417_current-presents-digg-dialogg-al-gore-on-manbearpig.htm :)
Sosyal mesajımızı Kyle'ın elinden vererek yazımı sonlandırıyorum. Görüşmek üzere.. :)
13 Mart 2011 Pazar
"Race Condition" Çözümleri
Herkese iyi akşamlar,
Bugün farklı bir kayıt girmek istiyorum. İşletim Sistemlerinden gideceğiz. Konumuz Race Condition'ı Çözmek...
Kısaca Race Condition ne demek onu hatırlayalım:ortak alana hangi process'in önce gireceği, oradaki değeri kimin alacağı ve nasıl değiştireceği gibi sorunlar en temel anlamda race condition'dır. İsminden belli zaten, process'ler birbirleriyle yarış halindedirler, alana girebilmek için. İşte bunun önüne nasıl geçebiliriz? Bugünkü konumuz başlıyor...
İki ana başlık altında inceleyebiliriz:
Lock Variables'a gelelim. Lock adında ortak bir değişken yaratırız. Kritik bölgeye girecek olan process "lock"a bakar. Lock=0(sıfır) ise girer, içerisi boş demektir. Lock=1 ise girmez, içerisi dolu demektir. Lock=0 iken bir process içeri girerse, Lock değeri 1 olur ve diğer "process"ler bu değerin sıfıra dönmesini beklerler. Ancak Lock'ın kendisi "race condition"a sebep olur.
Şöyle bir senaryo üzerinden anlatalım: A process'i lock değerine bakarken sleep moda düşsün. Ardından B process'i de lock'a baksın, boş olduğunu görsün ve o da sleep moda düşsün. Akabinde A process'i uyansın ve haliyle daha önce boş olduğunu gördüğü alana girsin. Ardından da B process'i uyansın ve o da en son kritik bölgenin boş olduğunu gördüğünden, alana girmeye teşebbüs etsin... The End! :)
Strict Alternation ise Lock Variables'ın aşağı yukarı aynısı. Onda da 1 ve 0 kontrolü yaparsınız. Bunda şu var: kritik alanın sıfıra dönmesini bekleyen process yavaş davranırsa, alana girememe ihtimali var. Örneğin büyük çapta I/O yapan bir process ise "rest in peace". :)
Gelelim Peterson's Solution'a. Bu yöntemde de bir dizi oluşturulur ve her process için dizide bir eleman tutulur. Her process dizide kendisi için tutulan variable'ı diğer yöntemlerdeki gibi 1 veya 0 yapar. Örneğin A process'i alana girdiğinde dizideki değişkenini 1 yapar. B process'i de diziye girememiş olur. A process'inin değişkeni sıfır olmadan B kendi değişkenini 1 yapamaz. Ancak aynı sorunlar bu yöntemde de mevcuttur.
TSL Instruction ise son Busy Waiting yöntemimiz. Bunda test ve lock işleri tek bir operasyonda olur. Donanımsal bir destekle yürütülen bu yöntem şöyle işler: A lock'a baktı. Sıfır olduğunu gördü. Önceki yöntemlerde sleep moda düşebiliyordu. Burda o engellenmiş. Yani A process'i için o değer 1'e çekilmeden, A process'ini sleep ettirmiyoruz.
Herşey muhteşem oldu diyorsanız, yanılıyorsunuz. Çünkü biz A process'inin sleep olmadan lock değerini bir yaptırdıktan sonra, lock sıfıra çekilinceye kadarB process'i bekliyor. Yani CPU zamanı boşa gitmiş oluyor. Ki bu tüm Busy Waiting yöntemlerinin ortak sorunu aslında. Peki ne yapabiliriz? İşte ikinci maddemiz... :)
Sleep And Wakeup yöntemi ile, bir process kritik alana girdiyse, ardından başka bir process de alana girmek istiyorsa, o istekli arkadaşı bloke ediyoruz. Yani içerisinin boşa düşmesini beklerken, CPU vakti de boşa harcanmamış oluyor zatı şahaneleri için. İçerisi boşa düştüğünde wakeup mesajı gönderiyoruz ve kendilerini uyandırıyoruz. Yalnız bu yöntemimizin de ufak mı ufak bir kusuru var. Ya "wakeup" mesajı kaybolursa... İşte böyle bir durum olursa, o process bir daha aramıza katılamaz.
Böylelikle Race Condition'a karşı geliştirilen yöntemleri görmüş olduk.
Görüşmek üzere..
Bugün farklı bir kayıt girmek istiyorum. İşletim Sistemlerinden gideceğiz. Konumuz Race Condition'ı Çözmek...
Kısaca Race Condition ne demek onu hatırlayalım:ortak alana hangi process'in önce gireceği, oradaki değeri kimin alacağı ve nasıl değiştireceği gibi sorunlar en temel anlamda race condition'dır. İsminden belli zaten, process'ler birbirleriyle yarış halindedirler, alana girebilmek için. İşte bunun önüne nasıl geçebiliriz? Bugünkü konumuz başlıyor...
İki ana başlık altında inceleyebiliriz:
- Busy Waiting
- Sleep and Wakeup
- Disabling Interrupts
- Lock Variables
- Strict Alternation
- Peterson's Solution
- TSL(Test and Set Lock) Instruction
Lock Variables'a gelelim. Lock adında ortak bir değişken yaratırız. Kritik bölgeye girecek olan process "lock"a bakar. Lock=0(sıfır) ise girer, içerisi boş demektir. Lock=1 ise girmez, içerisi dolu demektir. Lock=0 iken bir process içeri girerse, Lock değeri 1 olur ve diğer "process"ler bu değerin sıfıra dönmesini beklerler. Ancak Lock'ın kendisi "race condition"a sebep olur.
Şöyle bir senaryo üzerinden anlatalım: A process'i lock değerine bakarken sleep moda düşsün. Ardından B process'i de lock'a baksın, boş olduğunu görsün ve o da sleep moda düşsün. Akabinde A process'i uyansın ve haliyle daha önce boş olduğunu gördüğü alana girsin. Ardından da B process'i uyansın ve o da en son kritik bölgenin boş olduğunu gördüğünden, alana girmeye teşebbüs etsin... The End! :)
Strict Alternation ise Lock Variables'ın aşağı yukarı aynısı. Onda da 1 ve 0 kontrolü yaparsınız. Bunda şu var: kritik alanın sıfıra dönmesini bekleyen process yavaş davranırsa, alana girememe ihtimali var. Örneğin büyük çapta I/O yapan bir process ise "rest in peace". :)
Gelelim Peterson's Solution'a. Bu yöntemde de bir dizi oluşturulur ve her process için dizide bir eleman tutulur. Her process dizide kendisi için tutulan variable'ı diğer yöntemlerdeki gibi 1 veya 0 yapar. Örneğin A process'i alana girdiğinde dizideki değişkenini 1 yapar. B process'i de diziye girememiş olur. A process'inin değişkeni sıfır olmadan B kendi değişkenini 1 yapamaz. Ancak aynı sorunlar bu yöntemde de mevcuttur.
TSL Instruction ise son Busy Waiting yöntemimiz. Bunda test ve lock işleri tek bir operasyonda olur. Donanımsal bir destekle yürütülen bu yöntem şöyle işler: A lock'a baktı. Sıfır olduğunu gördü. Önceki yöntemlerde sleep moda düşebiliyordu. Burda o engellenmiş. Yani A process'i için o değer 1'e çekilmeden, A process'ini sleep ettirmiyoruz.
Herşey muhteşem oldu diyorsanız, yanılıyorsunuz. Çünkü biz A process'inin sleep olmadan lock değerini bir yaptırdıktan sonra, lock sıfıra çekilinceye kadarB process'i bekliyor. Yani CPU zamanı boşa gitmiş oluyor. Ki bu tüm Busy Waiting yöntemlerinin ortak sorunu aslında. Peki ne yapabiliriz? İşte ikinci maddemiz... :)
Sleep And Wakeup yöntemi ile, bir process kritik alana girdiyse, ardından başka bir process de alana girmek istiyorsa, o istekli arkadaşı bloke ediyoruz. Yani içerisinin boşa düşmesini beklerken, CPU vakti de boşa harcanmamış oluyor zatı şahaneleri için. İçerisi boşa düştüğünde wakeup mesajı gönderiyoruz ve kendilerini uyandırıyoruz. Yalnız bu yöntemimizin de ufak mı ufak bir kusuru var. Ya "wakeup" mesajı kaybolursa... İşte böyle bir durum olursa, o process bir daha aramıza katılamaz.
Böylelikle Race Condition'a karşı geliştirilen yöntemleri görmüş olduk.
Görüşmek üzere..
6 Mart 2011 Pazar
MSC
MSC, yani santraller... BSC'den (baz istasyonu merkezi) gelen talepleri alır ve ilgili yerlere iletir. Şebekelerin beyni desek yanlış olmaz herhalde.
MSC'leri "Processor Load" denilen mekanizmaları var. Bunlar da MSC'lerin CPU'larıdır. Bir MSC'deki yoğunluk %70 oranını geçerse, o MSC sallanmaya başlar. :) Daha önceki yazımda da bahsettiğim gibi, artık VLR denilen geçici kütükler de üzerlerine entegre haldedir. Bunun yararını daha iyi anlamak için bir iletişim senaryosu yazmam lazım ama düşünmem lazım onu. :)
MSC'yi etkileyen faktörlere bakalım hemen:
İkinci ve üçüncü maddeleri zaten anlamışsınızdır. İlk maddeden bahsedeyim biraz. Herhangi bir zaman diliminde Erlang'ın en yüksek olduğu zaman dilimi BH oluyor. Yani Busy Hour... Bir başka deyişle, konuşmaların sık olduğu zaman dilimi... Ancak bir uyarı yapayım. Bazı özel günlerde (Anneler Günü, Sevgililer Günü vs), bazı saatler daha çok artabiliyor. Veyahut operatörlerin kampanyaları olur geçici bir süreliğine... O açıdan BH hesabı yaparken bu tarz günleri hesaba katmayız.
Sonra görüşürüz.
MSC'leri "Processor Load" denilen mekanizmaları var. Bunlar da MSC'lerin CPU'larıdır. Bir MSC'deki yoğunluk %70 oranını geçerse, o MSC sallanmaya başlar. :) Daha önceki yazımda da bahsettiğim gibi, artık VLR denilen geçici kütükler de üzerlerine entegre haldedir. Bunun yararını daha iyi anlamak için bir iletişim senaryosu yazmam lazım ama düşünmem lazım onu. :)
MSC'yi etkileyen faktörlere bakalım hemen:
- BH Traffic (Erlangının artması)
- Number of Subscriber in VLR (Çok fazla abone kaydı)
- Processor Load (PL) (MSC'nin beyni demiştik az önce)
İkinci ve üçüncü maddeleri zaten anlamışsınızdır. İlk maddeden bahsedeyim biraz. Herhangi bir zaman diliminde Erlang'ın en yüksek olduğu zaman dilimi BH oluyor. Yani Busy Hour... Bir başka deyişle, konuşmaların sık olduğu zaman dilimi... Ancak bir uyarı yapayım. Bazı özel günlerde (Anneler Günü, Sevgililer Günü vs), bazı saatler daha çok artabiliyor. Veyahut operatörlerin kampanyaları olur geçici bir süreliğine... O açıdan BH hesabı yaparken bu tarz günleri hesaba katmayız.
Sonra görüşürüz.
InterMSC & Erlang
Kavramlara devam ediyoruz...
MSC'lerin santral demek olduklarından bahsetmiştik. InterMSC ise iki santralin haberleşmesine tekabül eder. İki adet MSC arasında birden fazla hat olabilir. Tabi bu hatlar çift yönlüdür. Örneğin 100 circuit mevcut olsun. MSC1 ve MSC2 arasında olsun bu "circuit"ler. MSC1'den MSC2'ye 70 tane; MSC2'den MSC1'e 30 tane çıkış olsun. Dolayısıyla MSC2 santralinin altında bulunan bir şahıs, MSC1 santrali altında bulunan bir şahsı aradığında daha fazla congestion(tıkanıklık) olabilir. Bunu kontrol eden yazılımlar da mevcut. Reklam yapmayacağım yine. :) Tıkanıklık kontrolüne göre MSC2'deki 30 çıkışı 40'a çıkarabilirsiniz mesela...
Erlang'a geçelim. Erlang bir "birim"dir. Bu birim ile ilgili teorik kısım ise şöyledir: 1 E1(PCM)-daha önceki yazılarda anlatmıştım- 1 saatte 1 Erlang taşır.
Birazdan görüşürüz..
MSC'lerin santral demek olduklarından bahsetmiştik. InterMSC ise iki santralin haberleşmesine tekabül eder. İki adet MSC arasında birden fazla hat olabilir. Tabi bu hatlar çift yönlüdür. Örneğin 100 circuit mevcut olsun. MSC1 ve MSC2 arasında olsun bu "circuit"ler. MSC1'den MSC2'ye 70 tane; MSC2'den MSC1'e 30 tane çıkış olsun. Dolayısıyla MSC2 santralinin altında bulunan bir şahıs, MSC1 santrali altında bulunan bir şahsı aradığında daha fazla congestion(tıkanıklık) olabilir. Bunu kontrol eden yazılımlar da mevcut. Reklam yapmayacağım yine. :) Tıkanıklık kontrolüne göre MSC2'deki 30 çıkışı 40'a çıkarabilirsiniz mesela...
Erlang'a geçelim. Erlang bir "birim"dir. Bu birim ile ilgili teorik kısım ise şöyledir: 1 E1(PCM)-daha önceki yazılarda anlatmıştım- 1 saatte 1 Erlang taşır.
Birazdan görüşürüz..
SS7 (Signalling System 7)
Merhaba arkadaşlar,
GSM'e kaldığımız yerden devam edelim. SS7'ye kısaca değinelim şimdi de. SS7, sinyalleşme demektir. Altyapısı oldukça güçlü ve arka planda bayağı işler dönüyor ama biz temel olarak değineceğiz. :)
SS7'nin nasıl çalıştığını anlatmadan önce iki bilindik terimden bahsedelim: offhook ve onhook. Offhook, telefonu kaldırmak, açmaktır. Sesin gelmesi değil, sadece telefonu kaldırmaktır. Onhook ise telefonu kapatmaktır.
Offhook yapılır yapılmaz, yani telefonu kaldırdığınız an, SS7 devreye girer. Santral(MSC) telefona çevir sesi yollanmasını sağlar. Yani çevir sesi telefondan gelmez, santral yollar o sesi. İki nokta arasında sinyalleşme sürer(kanallar vasıtasıyla), ta ki son sinyalde santralin numarayı algılamasına dek... Aranan şahıs da offhook yapınca -telefonunu kaldırınca- SS7 biter.
İki şahıs konuşmalarını bitirip herhangi bir tanesi de telefonunu kapattığı an SS7 yeniden devreye girer. Bu sefer de onhook sinyalleri gönderilir ve SS7 kullanılan o kanalı boşa çıkartır, bir başka konuşmacı çifti için...
SS7 kanaldan daima çift olarak gider gelir. Takribi %40-%60 oranıyla çiftler kullanır. Br yolunda arıza çıkarsa, diğer yolu da ilk yolu taşıyabilecek kapasitede olsun ister.
SS7 de genel anlamda böyle.. Görüşürüz birazdan.
GSM'e kaldığımız yerden devam edelim. SS7'ye kısaca değinelim şimdi de. SS7, sinyalleşme demektir. Altyapısı oldukça güçlü ve arka planda bayağı işler dönüyor ama biz temel olarak değineceğiz. :)
SS7'nin nasıl çalıştığını anlatmadan önce iki bilindik terimden bahsedelim: offhook ve onhook. Offhook, telefonu kaldırmak, açmaktır. Sesin gelmesi değil, sadece telefonu kaldırmaktır. Onhook ise telefonu kapatmaktır.
Offhook yapılır yapılmaz, yani telefonu kaldırdığınız an, SS7 devreye girer. Santral(MSC) telefona çevir sesi yollanmasını sağlar. Yani çevir sesi telefondan gelmez, santral yollar o sesi. İki nokta arasında sinyalleşme sürer(kanallar vasıtasıyla), ta ki son sinyalde santralin numarayı algılamasına dek... Aranan şahıs da offhook yapınca -telefonunu kaldırınca- SS7 biter.
İki şahıs konuşmalarını bitirip herhangi bir tanesi de telefonunu kapattığı an SS7 yeniden devreye girer. Bu sefer de onhook sinyalleri gönderilir ve SS7 kullanılan o kanalı boşa çıkartır, bir başka konuşmacı çifti için...
SS7 kanaldan daima çift olarak gider gelir. Takribi %40-%60 oranıyla çiftler kullanır. Br yolunda arıza çıkarsa, diğer yolu da ilk yolu taşıyabilecek kapasitede olsun ister.
SS7 de genel anlamda böyle.. Görüşürüz birazdan.
5 Mart 2011 Cumartesi
Bloguma Dokunma
"Diyarbakır 5. Asliye Ceza Mahkemesi’nin 14.01.2011 tarih ve 2011/156 D iş sayılı kararı ile Blogspot erişime kapatılmıştır.
Söz konusu suçlamaya karışmış kullanıcıların engellenmesi yerine, tüm kullanıcılar suçlama kapsamına alınarak erişimler engellenmiştir.
Bu imza kampanyası bu haksız engelin kaldırılması için düzenlenmiş olup, toplanılan imzalar 14.03.2011 tarihinde ilgili kurumlara iletilecektir.
Saygılarımızla."
Bloglara erişmek için DNS'lere müdahele de sürüyor. Bugün itibarıyla OpenDNS üzerinden de bloglara erişilemiyor. DNS'den çok ne var; bu engel, bunu yapanların zihniyetlerinde maalesef... Mesele blogumun okunması vs değil. Mesele insanların özgürlüklerine bu denli müdahele edilmesi ve aynı insanların hala bundan rahatsızlık duymaması. Vallahi yazık..
Kaydol:
Kayıtlar (Atom)