Aslında bu bölüm gerçekten uzun oldu. Normalde VCL kullanımını üçüncü bir bölüme taşımayı düşünüyordum. Ama bu konuda istekler olunca birleştrip yayınlamayı düşüdüm. İçeride sizi iki sayfalık bir makale bekliyor. Bu yüzden sayfa sonunda bitti zannedip kapatmayın!

Hazırsanız başlayalım.

Kanallar’ı Eş Zamanlı Olarak Çalıştırmak

Kanallar ile uğraşırken karşılaşılan en büyük sorunlardan bir tanesi de şüphesiz kanalları ortak bir şekilde sorunsuz olarak çalıştırmaktır. Eminim kanallar ile uğraşan birisi bütün kanallar tarafından ortak olarak kullanılan bir kaynağa erişmede problemlerle karşı karşıya gelmiştir ve kanalları bir köşeye itmesine sebep olmuştur.

Mesela şu veritabanı problemi size tanıdık gelecektir. Diyelim ki, iki adet kanalımız var ve bunlardan birincisi veritabanındaki bir kaydı açıp değişiklik yapmaya başladı. Sonra ikinci kanal aynı kaydın belli bölümlerinde düzenlemeler yaptıktan sonra veriyi kaydetti. Ardından birinci kanal, aynı verilerdeki değişikliğini bitirdi ve kaydetti. Birinci kanal, ikinci kanal’ın değişikliklerinden habersiz olduğundan ikinci kanalın yaptığı düzenlemeler de uçtu gitti.

Burada okuduğunuz problem, normalde kanallar ve veritabanı ile uğraşan bir çok programcının başına gelmiş bir problemdir. Bununla birlikte sadece veritabanında değil bir çok noktada özellikle bir dosyayı, bir portu, bir DLL’i veya başka bir şeyi, kanalların ortak kullanmasında hep benzer sıkıntılarla karşılaşılmıştır. Bu gibi sıkıntıların ve problemlerin çözümü kanalları eş zamanlı kullanım için kritik bölgeler tanımlamak ya da muteksleri kullanmaktır. Bu iki yöntem de makalemizin konuları arasındadır.

Kritik Bölgeler(Critical Sections)

Kritik Bölgeler -ya da başka yerlerde görebileceğiniz gibi kritik kesimler, bölümler, vs..- yukarıda anlatığımız problemdeki, birinci kanalın kaynağı kullanması esnasında ikinci kanalın bu kaynağa erişmesini englelemek için kullanılır. Birinci kanal işini yapıyorken, ikinci kanal’a çalışması için bir zaman dili ayrılmaz. Böylece birinci kanal işini bitirene kadar ikinci kanal çalıştırılmaz.

Bunun için örnek bir uygulamada yukarıdaki anlattığımız senaryolara benzer bir problem oluşturalım ve çözümünü aramaya çalışalım.

Diyelim ki, iki adet kanalımız var ve bu kanallar bir döngünün her adımında bir dizi işlem gerçekleştiriyor. Ve bu gerçekleştirdikleri işlemler için ortak kullandıkları global olarak tanımlanmış bir değişken olsun. Meseleyi anlatabilmek için iki kanalında yaptığı işlemlerin sonucunun aynı olmasını sağlamak istiyorum. Böylece problem daha iyi anlaşılabilecek.

Birinci kanal bir döngünün her adımında global değişkenimize teker teker harfler ekliyor ve sonuçta değişkenimizde bir yazı oluşuyor. Aynı işlemi ikinci kanalımız da yapıyor ve sonuç olarak birinci kanal ile aynı yazıyı üretiyorlar. Yanlız ikinci kanal harfleri teker teker eklemek yerine ikişer ikişer ekliyor. Ekleme işlemi çok hızlı olduğundan problemin oluşması için aralara Sleep rutinini ekleyerek işlemi birazcık yavaşlatıyoruz. Şimdi bu mantığımızı koda dökmeye başlayalım.

Yeni bir VCL uygulaması açalım ve bir adet button ekleyelim. Aşağıdaki gibi unitin var bloğunda global bir değişken tanımlayalım:

var
  Form1: TForm1;
  SonucYazi: string; //Global değişkenimiz

Ardından buttonun OnClick olayını aşağıdaki gibi değiştirelim.

procedure TForm1.Button1Click(Sender: TObject);
var
  Kanal1ID, Kanal2ID: DWORD;
begin
  CreateThread(nil, 0, @Kanal1, nil, 0, Kanal1ID);
  CreateThread(nil, 0, @Kanal2, nil, 0, Kanal2ID);
end;

Bu iki adet kanalımıza ait kanal fonksiyonlarını da aşağıdaki gibi oluşturalım:

procedure Kanal1;
procedure Kanal2;

...

implementation

...

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
  end;
end;

procedure Kanal2;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    SonucYazi := SonucYazi + 'di';
    Sleep(10);
    SonucYazi := SonucYazi + 'ye';
    SonucYazi := SonucYazi + 'zo';
    Sleep(10);
    SonucYazi := SonucYazi + 'n ';
  end;
end;

Gördüğünüz gibi iki kanal fonksiyonu da aynı sonucu üretiyor. Ama sonucu üretme yolları farklı. Ayrıca iki kanal da peş peşe oluşturulup çalıştırılıyor. Forma bir adet daha button ekleyelim ve bize sonucu göstersin. Bunun için ikinci butonumuzun OnClick olayını aşağıdaki gibi düzenleyelim:

procedure TForm1.Button2Click(Sender: TObject);
begin
  ShowMessage(SonucYazi);
end;

Bu programı çalıştırdıktan sonra ve kanalları birinci düğme ile çalıştırdıktan sonra sonuç yazının "diyezon diyezon diyezon …" gibi bir şey olmasını isteriz. Yani bir for döngüsünün bir adımı tamamlanmadan SonucYazi isimli global değişkene müdahale olmasını istemeyiz. Halbuki programı çalıştırdığınızda sonucun hiç de böyle olmadığını göreceğiz. Kanal1 işini bitirip "diyezon " yazmadan Kanal2 işe karışmış ve aralarda kendi harflerini eklemiştir. Hakeza bu, Kanal2 için de geçerlidir. Yani Kanal2, döngünün bir adımını bitirip istenilen sonucu veremeden Kanal1 global değişkenimize müdahale etmiştir.

Burada verdiğimiz örnek biraz soyut kaçabilir. Çünkü yaptığımız işlemden sonuç olarak elimize bir şey geçmiyor. Ama karşılaşacağınız sorunlar hep bu tarzda sorunlardır. Karşılaştığınız sorunları verdiğimiz bu örnek ile kıyaslama yapabilirsiniz. Mesela biz bu örneğimizde işlem adımlarını yavaşlatmak için Sleep rutinini kullandık. Normal hayatta kanallar ile uğraşırken zaten yaptığımız işlemlerin adımları Sleep rutinini aratmamaktadır. Mesela bir veritabanı tablosunda Edit ve Post gibi metodları kullandığımızda belli bir miktar işlemin tamamlanmasını bekleriz. Bir de eğer sizde sonuç düzgün çıkıyorsa yine söylüyorum işlemciniz, bu makaleyi yazdığım sıralardaki işlemcimden hızlı demektir. Bu durumda Sleep rutinine verdiğimiz değerleri çok az miktarlarda artırmayı deneyin.

Sadede gelelim ve problemi anladı isek şöyle bir soruyu kafamıza getirelim: Bir kanal belli bir işini bitirmeden önce diğer kanalların müdahalesini nasıl engelleyebiliriz?

Cevabı zaten bu bölümün başında verdik. Bunun için belli yerleri kritik bölge ilan edeceğiz. Bir kanalda kritik bölge ilan ettiğimiz yerdeki kodlar çalışmaya başladığı sırada, diğer kanallardaki aynı kritik bölgedeki kodlar işletilmez ve bekler. Yani aynı kritik bölgeye sahip kanallardan aynı anda sadece bir bölgedeki kodlar çalıştırılabilir. Böylece diğer kanalların istenilmeyen müdahalesi engellenmiş olur.

Bir Kritik bölge tanımlamak için bilmemiz gereken üç dört adet Windows apisi vardır.

InitializeCriticalSection: Bu fonksiyon kritik bölge’yi temsil eden recordun ilk değerlerini atamakla sorumludur. Yani kritik bölgeyi kullanıma hazırlamaktadır. Genelde formun OnCreate olayında kullanılır.

DeleteCriticalSection: Yukarıdaki fonksiyonun tam tersi olarak, bu fonksiyon da kritik bölgeyi ortadan kaldırır. Genelde formun OnDestroy olayına yerleştirilir.

EnterCriticalSection: Bu fonksiyonu çalıştırdığınız satırdan itibaren kritik bölgenin başlangıcını belirtirsiniz. Yani Delphi’deki "begin" kelimesi gibi düşünebilirsiniz.

LeaveCriticalSection: Bu fonksiyon ise, çalıştırıldığı satırla kritik bölgeyi sınırlandırır. Yine Delphi’deki "end" ifadesine benzetebiliriz.

Kritik bölgeyi temsil eden record ise TRTLCriticalSection tipindedir. Normalde Windows SDK yardım dosyalarında LPCRITICAL_SECTION şeklinde tanımlanmıştır. Ama Delphi ekibi bir çok windows yapısını tanımlarken bunlara "T" ile başlayan daha iyi okunur alias isimler vermişler. Her neyse…

Kritik bölgenin tanımlanması gayet basittir. Bir kritik bölgeyi işletim sistemine tanıtmak için InitializeCriticalSection fonksiyonunu kullanıyoruz. Kritik bölge ile işimiz bittiğinde de DeleteCriticalSection fonksiyonunu çağırmayı unutmuyoruz. Ardından kanal fonksiyonlarımızda kritik bölgeleri belirleyip başına EnterCriticalSection ve sonuna LeaveCriticalSection sonksiyonlarını koyuyoruz.

Örneğimize dönelim ve kritik bölgeleri eklemeye başlayalım. Bizim müdahale istemediğimiz bölge, kanal fonksiyonlarındaki döngülerin her bir adımıdır. Yani teker teker veya ikişer ikişer ekleme yapılan kısımlarda bir adım işini bitirmeden başka bir kanalın global değişkenimize müdahalesini engellemek istiyoruz. Kısacası kritik bölgemiz bu örnekte, döngünün her bir adımı olmalıdır.

İlk başta global olarak bir değişken daha tanımlayalım. Bu değişken bizim kritik bölgemizi temsil eden record olsun.

var
  Form1: TForm1;
  SonucYazi: string;
  BirinciKritikBolge: TRTLCriticalSection; //kritik bölgemizi temsil ediyor.

Ardından formun OnCreate ve OnDestroy olaylarını aşağıdaki gibi değiştirelim.

procedure TForm1.FormCreate(Sender: TObject);
begin
  InitializeCriticalSection(BirinciKritikBolge);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  DeleteCriticalSection(BirinciKritikBolge);
end;

Eğer başka kritik bölgeler de tanımlamış iseniz bunları da InitializeCriticalSection ve DeleteCriticalSection fonksiyonlarını kullanarak oluşturmalı ve silme işlemlerini gerçekleştirmelisiniz. Bizim örneğimizde bir adet kritik bölge yeterlidir.

Şimidi kanal fonksiyonlarında bahsettiğimiz yerleri kritik bölge olarak ilan edelim.

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    EnterCriticalSection(BirinciKritikBolge); //BirinciKritikBolge başlangıcı
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
    LeaveCriticalSection(BirinciKritikBolge); //BirinciKritikBolge bitişi
  end;
end;

procedure Kanal2;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    EnterCriticalSection(BirinciKritikBolge); //BirinciKritikBolge başlangıcı
    SonucYazi := SonucYazi + 'di';
    Sleep(10);
    SonucYazi := SonucYazi + 'ye';
    SonucYazi := SonucYazi + 'zo';
    Sleep(10);
    SonucYazi := SonucYazi + 'n ';
    LeaveCriticalSection(BirinciKritikBolge); //BirinciKritikBolge bitişi
  end;
end;

Yapacağımız başka bir işlem kalmadı. Programı çalıştırıp deneybiliriz. Sonucun "diyezon diyezon diyezon …" gibi düzgün olduğunu göreceğiz. Çünkü Kritik bölge tanımlayarak sadece bir kanalın kritik bölgesini çalıştırmış olduk. Böylece bir kanal global SonucYazi değişkeni ile uğraşırken diğer kanal buna müdahale edemeyecektir.

Burada bir adet kritik bölge tanımladık. Sizler ihtiyaca göre projelerinizde bir çok kritik bölge tanımlayabilirsiniz. Ayrıca kritik bölgelerin birbirinden bağımsız hareket ettiğini de aklınızdan çıkarmayın. Bazen karıştırılan nokta bu kısım olabiliyor. Mesela bu örneğimizde bir adet kritik bölge mevcut ama iki farklı yapılan iş var.

Gördüğünüz gibi kanalları eş zamanlı olarak çalıştırmak o kadar da zor değilmiş. Tek yaptığımız bell bölgeleri kritik bölge olarak ilan etmek. Şimdi yeni bir kavramla daha tanışalım.

Muteksler(Mutex)

İngilizce’ de, mutual ve exclusive kelimelerinin birleşiminden meydana gelmiştir. Dilimizde ise müşterek ve seçkin kelimeleri bu kelimeleri karşılamaktadır. Programlama terminolojisinde ise, sadece tek işlemdeki değil birden fazla işlemdeki kanalları eş zamanlı olarak kullanılmasını sağlayan bir tekniktir.

Bir mutekse aynı anda sadece bir tek kanal sahip olabilir. Literatürde, bu mutekse, bir kanal sahip olduğunda, muteksin kanal tarafından "tetiklendiği" ya da "tutulduğu" söylenir. Aynı şekilde eğer kanal bu mutekse sahip deiğilse muteks "serbestir" ya da "tetiklenmemiştir" tabirleri kullanılır.

Şu an kafanızda mutekslerin ne olduğuna dair somut bir düşünce oluşmamış olabilir. Ama bölümün sonuna kadar okuduğunuzda neyin ne olduğuna dair bir fikir oluşacağına eminim.

Bir muteks, CreateMutex fonksiyonu ile oluşturulur. Bu fonksiyonun tanımlanması ve açıklaması aşağıdadır.

function CreateMutex(lpMutexAttributes: PSecurityAttributes;
  bInitialOwner: BOOL;
  lpName: PChar): THandle;

lpMutexAttributes: Muteksin güvenliği ile ilgli parametredir. Bu parametreye nil girerek varsayılan güvenlik özelliklerini ayarlamış oluyoruz.

bInitialOwner: Kanalın bu mutekse sahip olup olmadığını ya da yukarıda bahsettiğimiz gibi muteksin tetiklenip tetiklenmeyeceğini belirler. True ya da False giriyoruz. Genelde muteksi programın ana kanalında oluşturduğumuzdan, ana kanalın mutekse sahip olmasını istemeyiz. Bu yüzden genelde bu parametreye False gireriz.

lpName: Eğer farklı işlemler bu mutekse erişecekse bu muteksimize bir isim vermemiz gerekmektedir. Buraya nil de girebilirisiniz. Bu durumda isimsiz bir muteksimiz olur.

Bu fonksiyon eğer muteksi oluşturabilirse çıktı olarak muteksin handle numarasını dönderir. Eğer muteks oluşmamış ise 0 değerini çıktı olarak verir.

Muteksleri, kritik bölgeler gibi düşünebilirsiniz. Kritik bölge oluşturmak için kullandığımız InitializeCriticalSection fonksiyonu yerine CreateMutex fonksiyonunu, kritik bölgenin başlangıcını belirten EnterCriticalSection yerine WaitForSingleObject fonksiyonunu, kritik bölgenin bitişini bildiren LeaveCriticalSection fonksiyonu yerine de ReleaseMutex fonksiyonunu kullanıyoruz. CloseHandle ile de CreateMutex ile oluşan muteksin handle’ını kapatmayı da unutmuyoruz.

İlk önce bir muteks oluşturalım.

birmuteks := CreateMutex(nil, False, 'ornekmuteks');

Ardından kritik bölgeyi oluşturduğumuz yerlerdeki fonksiyonları muteksin fonksiyonları ile yer değiştiriyoruz. Şimdilik sadece Kanal1 için örnek verelim.

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    WaitForSingleObject(birmuteks, INFINITE); //Muteksin tetiklenmesini bekle
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
    ReleaseMutex(birmuteks); //Muteksi serbest bırak.
  end;
end;

Şimdi muteksin ne olduğuna dair kafanızda bir şeyler şekillenmeye başlmamıştır. Çünkü kodlara baktığımızda WaitForSingleObject fonksiyonu bir şeyleri bekliyor ve ReleaseMutex ise bir şeyi serbest bırakıyor. WaitForSingleObject, "tek bir nesne için bekle" gibi bir manası var. Esas yaptığı görev, birinci parametresinde verilen handle numarasına göre bir muteksi beklemektir. İkinci parametresinde ise ne kadar bekleyeceğini belirliyoruz. Bu örneğimizde INFINITE (sonsuz) girmekle, bir muteks tetiklenene kadar bekleyeceğini belirttik. Bu parametreye, en fazla ne kadar bekleneceğini milisaniye şeklinde girebilirsiniz.

Muteksi anlamada genelde verilen örnek ve bence en iyi örnek bayrak yarışıdır. Bayrak yarışlarında bir şeritte ancak bir koşucu koşabilir. Bayrağı alan koşmaya başlar. Bir şeritte, bayrağa sahip olmayan, koşabilmek için bayrağı beklemesi gerekmektedir. Böyelece her bir şeritte sadece bir yarışçı koşabilir.

Aynen bunun gibi, kanallar çalışabilmek için mutekse sahip olmaları gerekmektedir. Mutekse sahip olan koşmaya yani çalışmaya başlar. Mutekse sahip olmayan, muteksin kendisine gelmesini bekler. Bir hatırlatma olarak, önceki paragraflarda sahip olmanın tetiklemek olduğundan bahsetmiştik.

İşte WaitForSingleObject ile muteksin bu kanalımıza gelmesini beklemiş oluyoruz. Ve bunu örneğimizde, INFINTE yani sonsuz süre kadar bekliyoruz. Ve muteksle işimiz bittiğinde diğer kanalların kullanabilmesi için muteksi ReleaseMutex ile serbest bırakıyoruz. Ve yine tekrar ediyorum "Bir mutekse aynı anda sadece bir tek kanal sahip olabilir."

CreateMutex ile oluşturduğumuz muteksin handle’nı formun OnDestroy olayında CloseHandle ile kapatmayı da unutmuyoruz. Yani kritik bölgelerde yaptığımız DeleteCriticalSection yerine

CloseHandle(birmuteks);

gibi bir şey yazmalıyız.

Bu örneği, makaleyi fazla uzatmasın diye, burada tüm kodlarını yazmayacağım. Muteks örnek projesini buradan indirebilirsiniz.

Eğer tek bir muteks değil de bir den fazla muteksi tetiklemesini bekelemek istersek ne olacak? Bu durumda WaiıtForMultipleObjects fonksiyonunu kullanacağız. WaitForSingleObject tek bir muteksi beklerken WaitForMultipleObject fonksiyonu birden fazla muteksi beklemektedir. Kullanım aynı olduğu için bununla ilgili bir örnek yapmayacağım. Bu fonksiyon ile iligli tek söyleyebileceğim şey ikinci parametrede beklediğiniz mutekslerin handle’larını dizi şeklinde girmeniz olacaktır.

Başka İşlemlerden Mutekslere Sahip Olma

Dediğimiz gibi, mantık olarak mutekslerin kritik bölgelerden tek farkı, başka program ve işlemlerdeki kanallar ile ortak ve eş zamanlı çalışmaya izin vermesidir. Bunun için muteksimize bir isim vermemiz gerektiğini söylemiştik. İşte bu ismi kullanarak başka bir işlem muteksin handle numarasını alabilir. Gerisinde de WaitForSingleObject ve ReleaseMutex fonksiyonlarında bu handle numarasını kullanabiliriz. Yani mevcut bir muteksin handle numarasını alabilmek için:

birmuteks := OpenMutex(0, False, 'ornekmuteks');

dememiz yeterli. Bunu yukarıdaki örneğimizde CreateMutex yerine kullanabilirsiniz. Ama unutmamanınız gereken nokta bunun ile mevcut bir muteksin handle numarasını alırız. Eğer muteks CreateMutex ile hiç oluşturulmamış ise bu fonksiyon 0 değerini dönderir.

OpenMutex fonksiyonunun parametreleri CreateMutex ile aynı olduğundan burada fazladan bir açıklama yapmayacağım.

Bu konuda bir örnek yapmak isterseniz yukarıda verdiğimiz örneği iki uygulamaya bölebilirsiniz. Kanal1‘i birinci uygulamada, Kanal2‘yi de ikinci uygulamada oluşturursunuz. Ve ikisinde de OnCreate olayında şöyle bir şey girersiniz:

var
  BirMuteks: THandle;
.....
procedure TForm1.OnCreate(....);
begin
  BirMuteks := OpenMutex(0, False, 'ornekmuteks');
  if BirMuteks = 0 then
    BirMuteks := CreateMutex(nil, False, 'ornekmuteks');

Kısaca burada yaptığımız işlem eğer "ornekmuteks" isminde bir mutex henüz oluşturulmamış ise oluşturuyoruz.

Bu şekilde iki veya daha fazla sayıda işlem tek bir muteks üzerinde kanallarını eş zamanlı olarak çalıştırabilirler. Bu örneği kendiniz yapmaya çalışın. Gerçi burada yapılmışı var . Ama lütfen indirip incelemeden önce kendiniz yapmayı deneyin.

—

İşte size iki adet yöntem. Ve ikisi de windows programlamada çok sık kullanılmaktadır. Kanalları beraber çalıştırmak istediğinizde, istrer muteks kullanın isterseniz kritik bölge tanımlayın. Her ikisinin de tanımlanması ve kullanılması çok kolay. Kafanızdaki "kanal kullanmak çok zordur" düşüncesini birinci bölümde aştığınızı düşünüyorum. Buraya kadar olan kısım ile de "kanalları eş zamanlı çalıştırmak zordur" düşüncesini yendiğinizi zannediyorum.

Peki muteks ve kritik bölge arasında tercih yapmak gerekirse hangisini tercih etmeliyiz. Bence performans açısından pek fark olmaz. Seçim noktanız şu olmalı. Eğer, tek bir işlemden değil de bir çok işlemden yani bir çok programdan oluşan bir gurubun kanalları ortak ve eş zamanlı kullanmasını düşünüyorsak kesinlikle muteks kullanmalıyız. Aksi durumda yani eş zamanlı çalışacak olan kanallar sadece tek bir işlemde bulunuyorlarsa o zaman seçim size kalmış. Hangisi rahatınıza gidiyorsa onu kullanabilirsiniz.

Şimdi farklı bir konuya geçiş yapalım. Hazırsanız ikinci sayfadan devem edelim.

Bu makale, ileri seviye Windows programcılığına geçiş kapısıdır. Bu makeledeki konuları öğrendikten sonra Win32 programcılığının en güçlü özelliklerini öğrenmiş olacaksınız.

Yanlız "ileri seviye" tabiri gözünüzü korkutmasın. Çünkü makeleyi bitirdiğinizde thread kullanımının aslında ne kadar kolay olduğunu göreceksiniz. Bununla birlikte bu makalede bu konu ile ilgili her ayrıntıyı anlatabilmemiz için yüzlerce sayfalık kitap yazmamız gereklidir. Bu yüzden burada işin mantığını kapıp, ihtiyacınız oldukça yardım dosyalarına müracaat etmeniz gerekebilir.

Kanallar hakkında hiç bir bilginiz olmayabilir. Bu makalede işin temelinden alacağız ve makaleyi bitirdiğinizde kendi programlarınıza kanal ekleyebilecek duruma geleceğinize inanıyorum.

Bu makale serisinde kanallar temelden anlatılmakla beraber, ileri seviye kanal kullanımı, VCL bileşenlerinde kanal kullanımı ve Muteksler de ana konularımız arasına girecektir.

Giriş

İlk başta bir kaç teorik bilgi ile başlamak istiyorum. Bu bilgilieri olabildiğince sıkmadan, kısa tutmaya çalışacağım.

Disk üzerindeki her bir dosya çalıştırıldığında artık windows için birer işlem(process) olurlar. Bir işlem Windows için fazla bir şey ifade etmez. Çünkü işlemler sadece hafızada belli bir bölgede var olmaktan sorumludur. Esas işlemi yapan kısım kanallardır(thread). Bir işlem en az bir adet kanala sahiptir. Win 3.1 gibi işletim sistemleri sadece bir adet kanala sahiptir. Ama Windows 95 ve üstü, Unix, OSX gibi işletim sistemleri birden fazla kanala sahip olabilirler.

İşletim sistemi bir programı ya da bir DLL’i ilk başta işlem olarak hafızaya taşır. Bu esnada işlem eylemsiz olarak durur. Bu işleme ait kanallar ise bizim belirlediğimiz ölçüde programın kodlarını çalıştırmaya başlar.

Her kanal, çalışma esnasında kendi eax, ebx, edx gibi register verilerini tutan bir yapıya sahiptir. Bu yapıya context(içerik) adı verilmektedir. Bu yapının Delphi’deki karşılığı TContext olup, Windows unitindedir. Bu record tipini incelediğinizde bir çok register’ı barındırdığını göreceksiniz. Eğer buradaki Delphi ve Assembler ile ilgili makaleyi ve buradaki fonksiyon çağırım makenizmalarını okudu iseniz şimdi anlatacaklarımız size tanıdık gelecektir. Çünkü kanalların işleyiş mantığı fonksiyon çağırımlarına benzemektedir. Ama devam edebilmek için bunları okumak zorunda değilsiniz.

Her bir kanal sahip olduğu önceliğe göre işletim sistemi tarafından işleme alınacaktır. Bu işleme alış esnasında sahip olduğu context‘deki register değerleri yüklenir. Esp, Ebp, Eip gibi registerlar da yüklendiğinden, kanal önceden kaldığı yerden önceki stack değerlerine göre işlemine devam edecektir. Ve yine önceliğine göre belli bir süre sonunda işletim sistemi bu kanalı durdurup register değerlerini context yapısında saklar. Daha sonra diğer bir kanalın context verisini yükleyerek başka bir kanalı işlemeye geçer. Ve hakeza bu işlem tüm kanallar için devam edip gider. İşletilme ve geçiş süreleri çok kısa olduğundan, biz sanki aynı anda tüm kanallar işletiliyormuş gibi zannederiz. Halbuki bütün kanallar belli bir sıra ile çok kısa sürelerde işletilip diğer bir kanala geçilmektedir. Yani her kanal aynı anda çalışmaz, biz öyle zannederiz. Tabi bu anlattıklarımız tek işlemci ve tek çekirdek için geçerlidir. Kanalların işletilme sürelerini ise kanalların önceliği belirlemektedir. Hangi kanal daha yüksek öncelikli ise o kanal daha fazla işletilme süresine sahip olur. Eğer kanal arkaplanda çalışma üzere ayarlanmış ise, diğer kanallar işlemlerini tamamladıktan sonra ancak bu kanala sıra gelecektir. Eğer kanal çok yüksek önceliğe sahip ise uzun bir süre bu kanal işleme devam edecek ve diğer kanallara sıra gelmeyecektir.

Demek ki, aynı anda bir kaç işlem yapmak istiyorsak kafa patlatıp, parmak yormamıza gerek yokmuş. Çünkü işletim sistemi zaten sizin için bu sistemi kurmuştur. Sadece biraz vaktiniz ayırmanız ve kanallar nasıl oluşturuluyor öğrenmeniz yeterlidir.

Kanal Oluşturma Yöntemleri

Aslında böyle bir başlıkla konuya giriş yapmak istemezdim. Ama kanal oluşturmayı öğrenmeden önce bir kaç şeyi açığa kavuşturmak istiyorum. Gerek forumlardan gerekse haber guruplarından kanallarla ilgili gelen sorulardan bir çoğu kanalların yanlış oluşturulması üzerine kaynaklanan yanlışlıklardan gelmektedir.

Normalde bir kanal windows ortamında CreateThread Windows API’si ile oluşturulur. Fakat VCL bize TThread isminde bir sınıf da sunmuştur. Kullanım açısından ayırt edebileceğiniz temel nokta şudur. Eğer kanalda yapacağınız işlemler VCL sınıflarını etkilemesi gerekiyorsa TThread sınıfını kanal oluşturmak için kullanıyoruz. Yok eğer VCL sınıflarını ilgilendiren bir işlem söz konusu değilse CreateThread API’sini kullanıyoruz. Bunun neden böyle olduğunu ileride VCL ve Kanal kullanımı ile alakalı başlıkda vereceğim. Muhtemelen Bölüm 2′de göreceksiniz. Bu yüzden biraz sabır.

Başlarken bu şekilde bir giriş yapmamın sebibi buradan kaynaklanıyor. Bir çok kişi belki de Windows API’lerine karşı bir soğukluktan dolayı CreateThread ile uğraşmak istemiyor ve CreateThread ile ilgili kısımları gözü kapalı atlayabiliyor. Bu yüzden eksik kanal bilgisi ile ileride bir çok sorunla karşılaşabiliyor. Ama şimdi göreceğimiz gibi kanal oluşturma işlemi sanıldığı kadar zor ve karmaşık bir işlem değil.

Bir Kanal Oluşturalım

Kanal oluşturma ile sorumlu Windows fonksiyonu CreateThread fonksiyonudur ve aşağıdaki gibi tanımlanmıştır:

function CreateThread(lpThreadAttributes: Pointer;
  dwStackSize: DWORD; lpStartAddress: TFNThreadStartRoutine;
  lpParameter: Pointer; dwCreationFlags: DWORD; var lpThreadId: DWORD): THandle; stdcall;

Bu fonksiyonun parametrelerinin kısaca açıklamasını verelim.

lpThreadAttributes: Kanalımıza atanacak olan bir çok güvenlik özelliğini belirtmemize yarar. Eğer nil girerseniz varsayılan güvenlik özellikleri kullanılacaktır. Win9x ve WinMe için bu değer nil olmalıdır. Bu konu ile alakalı daha fazla bilgi almak için sdk yardım dosyalarından SECURITY_ATTRIBUTES başlığına müracaat edebilirsiniz.

dwStackSize: Eğer kanal için özel bir stack büyüklüğü belirlemeyecekseniz bu değeri 0 olarak girmelisiniz. Böylelikle kanalın stack büyüklüğü program ile aynı olacaktır. Gerektiğinde stack boyutu otomatik olarak genişletilebilir.

lpStartAddress: Bu parametre esas işi gören parametredir. Çünkü kanal çalışmaya bu parametredeki fonksiyon işaretçisi ile beraber başlar. Burada tek yapmamız gereken fonksiyonun isminin önüne @ işareti vererek girmektir.

lpParameter: Bir önceki parametrede girdiğimiz kanal fonksiyonuna parametre yollamak istiyorsanız, bu parametrelerin içinde bulunduğu bir record’un adresini buraya girmelisiniz. Ayrıca record haricinde karakter veya sayı değelerini de parametre olarak yollayabiliriz.

dwCreationFlags: Bu parametre ile kanalın oluşturulur oluşturulmaz çalışıp çalışmayacağını belirliyoruz. Eğer bu parametreye CREATE_SUSPENDED girerseniz, kanal oluşturulur fakat kendisine çalışmaya başlaması için izin verilmez. Bu durumda siz ResumeThread fonksiyonu ile bu kanala çalışma talimatı vermedikçe kanal o şekilde çalışmadan duracaktır. Bir kez ResumeThread ile çalışmaya başladıktan sonra SuspendThread ile tekrar kanalı durdurabilirsiniz. Eğer bu parametreye 0 girerseniz, kanal oluşturulur oluşturulmaz çalışmak için sıraya girecektir.

lpThreadId: Bu parametreye kanal kimlik ID’si atanır. Buraya değeri olmayan bir Dword değişken giriyoruz. Değişken gireceğiz çünkü "var" olarak tanımlanmış. Çünkü kanal oluşturulduktan sonra Windows NT,2000 ve üstü işletim sistemlerinde kanalın ID’si bu değişkene yüklenir. Windows 9x/Me işletim sistemlerinde bu değer daima 0′dır.

Şimdi gelin bu fonksiyonu kullanarak bir kanal oluşturalım.

var
  KanalID: DWORD;
begin
  CreateThread(nil, 0, @KanalFonksiyonu, nil, 0, KanalID);

İşte hepsi bu! Tek yaptığımız sadece gerekli parametreleri kullanmak, gerisini duruma göre nil veya 0 yapmak. Bu fonskiyon çağrıldığında KanalFonksiyonu isimli fonksiyonumuz kanal içinde çalışmaya başlayacaktır.

Dilerseniz KanalFonksiyonu isimli fonksiyonumuzun tanımlamasını şimdi yapacağımız örnek içinde verelim.

Basit Bir Örnek

Şimdi oluşturduğumuz bu kanalın nasıl çalıştığını basit bir örnek ile görmeye çalışalım. Yeni bir uygulama oluşturalım ve Form üzerine bir adet button ve bir adet label koyalım. Button’nun Caption özelliğini "Oluştur ve Çalıştır" olarak değiştirelim. Ve Button’nun OnClick olayına kanalımızı oluşturan şu kodları girelim:

procedure TForm1.Button1Click(Sender: TObject);
var
  KimlikID: DWORD;
begin
  CreateThread(nil, 0, @KanalFonksiyonu, nil, 0, KimlikID);
end;

Şimdi de kanalımızda esas işi yapan KanalFonksiyonu isimli fonksiyonumuzun tanımlamasını girelim:

function KanalFonksiyonu(P: Pointer): Longint; stdcall;

...

implementation

...

function KanalFonksiyonu(P: Pointer): Longint; stdcall;
var
  i: Integer;
  Toplam: Int64;
begin
  Toplam := 0;
  for i := 0 to 1000000000 do
  begin
    Toplam := Toplam + i;
    Toplam := Toplam shl 4;
  end;
  Form1.Label1.Caption := 'Kanal işlemini tamamladı. Sonuç:' + IntToStr(Toplam);
end;

Bu fonksiyonda ekstra bir şey yapmıyoruz. Sadece bir for döngüsü var ve matematiksel bir işlem yapılıyor. For döngüsü bittiğinde ise formdaki label’a bir sonuç yazdırıyoruz.

Bu for döngüsünü, ayrı bir kanalda değil de programın ana kanalında çalıştırmaya kalksaydık muhtemelen Application.ProcessMessages ve TTimer gibi çözümlere gidecektik. Bu durum da çok fazla miktarda performans düşüklüğüne sebep olacaktı. Ayrıca işlemlerimiz genelde buradaki gibi basit matematiksel işlemler olmadığından, programda çökmelere ve donmalara sebep olacaktık.

Bu programı çalıştıralım ama button’a basmayalım. Eğer açık değilse View menüsünden "Thread Status" penceresini ve "Event Log" penceresini açalım ve görebileceğimiz bir köşeye yerleştirelim. Eğer BDS 2005 ve üstü kullanıyorsanız bu pencereler debug esnasında altta görünür biçimde hazır olacaklardır.

Ardından buttona bir kez basalım ve "Thread Status" penceresine yeni bir eleman eklendiğine dikkat edelim. Eğer buradaki eleman çok çabuk bir şekilde görünüp kayboldu ise işlemciniz benimkinden hızlı demektir . Bu yüzden for döngüsündeki limit değeri biraz artırıp tekrar çalıştıralım.

Button’a her tıkladığınızda "Thread Status" pencersinden de takip edebileceğiniz gibi yeni bir kanal eklenecek. Tabi butona basma işini o kadar çok abartmayın. Her kanal oluşturulduğunda kendisine bir ID atanacak. Örneğimizde bu değer KimlikID değişkeninde tutuluyor. "Thread Status" pencersinde ise ThreadID sütununda bu değeri görebiliriz. Her kanal işlemini bitirdiğinde "Thread Status" pencersinden kaybolduğunu göreceksiniz. Aynı şekilde "Event Log" pencersinde de kanal’ın ID’sine göre başlama ve bitişi ile ilgili mesajları görebilirsiniz.

Kanal çalışırken program üzerinde istediğiniz işleme devam edebilirsiniz. Formu taşıyabilir, boyutlandırabilir, başka bileşen ve nesneler var ise onları kullanabilirsiniz. Ve bunu yaparken bir yandan kanal(lar) da çalışmaktadır. Aynı kanal fonksiyonunu doğrudan çağırmaya kalktığımızda formumuza döngü bitene kadar müdahale edemeyecektik.

Gördüğünüz gibi bir kaç satır kod ile kanal oluşturuveriyoruz. Tek bilmemiz gereken kısım CreateThread fonksiyonunun parametreleri. Bunların çoğunu da kullanmadık. Ama makalenin ilerleyen kısımlarında bunları da yavaş yavaş kullanıma dahil edeceğiz. İşte bir tanesi geliyor.

Kanal Fonksiyonlarına Parametre Gönderimi

CreateThread fonksiyonunun parametrelerini açıklarken lpParameter‘den söz etmiştik ve bu parametre ile kanal fonksiyonuna istediğimiz parametreyi gönderebileceğimizi belirtmiştik. Şimdi bunu nasıl yapacağımızı görelim.

Bunun için yukarıda yaptğımız örnekten faydalanacağız. İlk başta type bloğunda aşağıdaki record tanımlamasını yapalım.

  PKanalParametresi = ^TKanalParametresi;
  TKanalParametresi = record
    BirParametre: string;
  end;

Ardından kanal fonksiyonumuzu aşağıdaki gibi değiştirelim.

function KanalFonksiyonu(P: Pointer): Longint; stdcall;
var
  Parametreler: PKanalParametresi;
begin
  Parametreler := PKanalParametresi(P); //Parametremizi alalım.
  while True do
  begin
    Form1.Label1.Caption := Form1.Label1.Caption + Parametreler^.BirParametre;
    Sleep(1000); //İşlemcinin %99 çalışmasını istemiyiz değil mi....
  end;
  Dispose(Parametreler);
end;

En son olarak button’nun OnClick olayını da aşağıdaki gibi olacak şekilde değiştirelim.

procedure TForm1.Button1Click(Sender: TObject);
var
  KimlikID: DWORD;
  Parametreler: PKanalParametresi;
begin
  New(Parametreler);
  Parametreler^.BirParametre := 'a';
  CreateThread(nil, 0, @KanalFonksiyonu, Parametreler, 0, KimlikID);
end;

Aslında çok fazla bir şey yapmadık(en azından siz kopyala yapıştır yaptınız:) ). Burada basit bir işaretçi kullanımını görüyoruz. Ve parametre olarak bir record’u kullandık. Record yerine başka veri tiplerini de kullanabilirdik. Ama genelde karşılaşılan sorunlar recordları parametre olarak yollamaktan gelmektedir.

En başta verdiğimiz record tanımlamasına bakarsanız, PKanalParametresi isminde bu recordumuza işaretçi olan bir tip göreceksiniz. Parametremizi işaretçi olarak kullanacağımızdan bu tipe ihtiyacımız olacak. Ardından Button’nun OnClick olayına bakalım. Burada önceki örneğe göre fazladan 2 satır ekledik. İlk başta var bloğunda Parametreler isminde bir record işaretçisi tanımladık. Ardından işaretçi hiç bir şey ifade etmediğinden, işaretçiye ait bir recordun hafızada oluşturulması için New rutinini kullandık. Devamında bu record’un değişkenlerinden birine bir string değer atadık. CreateThread fonksiyonu parametreyi işaretçi olarak istediğinden buraya direk olarak Parametreler değişkenimizi girebiliriz. Çünkü bu değişken bir record işaretçsidir.

En son olarak yeni kanal fonksiyonumuza baktığımızda, işaretçi olarak gelen parametremizin nasıl kullanıldığını görüyoruz. Burada bizim için önemli olan kısım Dispose kısmıdır. Çünkü burada New ile oluşturduğumuz ve işaretçiye ait olan recordu hafızadan siliyoruz.

Record işaretçisi yerine normal record kullansa idik ve sonra da bunu parametre olarak geçirirken pointer olarak geçirse idik olmazmıydı. Olurdu… Üstelik New ve Dispose rutinlerini de kullanmak zorunda kalmazdık. Ama, bu durumda boş yere hafızda yer işgal edecektik. Çünkü parametre recordu sadece bir kerelik işimize yarayacak. Bu yüzden işimiz bitince Dispose ile hafızdan siliyoruz.

Bu örneğimizi de çalıştırıp deneyebilirsiniz. Ayrıca Görev Yöneticisi ile işlemciyi yüzde kaç kullandığını da görebilirsiniz. Tabi burada Sleep rutinini kullanmak yerine daha başka yapılabilecek şeyler var ama şimdilik kafa karıştırmamak için bunları sonraya bırakıyorum.

Sonuç

Bu bölümü burada noktalayalım. Gelecek bölümde kanalların nasıl birbirleri ile birlikte çalışabileceğini göreceğiz. Ayrıca Mutex’ler ve VCL ile kanal kullanımı da gelecek bölümde göreceğimiz konular arasında olacak. Böylece kanallar konusunda hiç bir şüpheniz, korkunuz kalmayacağı gibi programlarınıza da profesyonellik katacaksınız.

Gelecek bölümde buluşmak ümidi ile… Yorumlarınızı ve eleştirilerinizi bekliyorum. Yine her zaman ki gibi sorularınızı buradan yada Delphi Türkiye forumlarından iletebilirsiniz

Fatih Tolga Ata © 2007

Kaynaklar

• Windows SDK Yardım Dosyası
• Delphi 4 Unleashed, Charlie Calvert, Sams Pub., 1999

Bölüm 1 – Giriş

Bölüm 2 – Okuma ve Yazma

Bölüm 3 – Server

TIdTCPServer

En önemli Indy server, TIdTCPServer bileşenidir. TIdTCPServer, programın ana kanalından bağımsız olan ikincil bir dinleme kanalı oluşturur. Dinleme kanalı, client’den gelen istekleri bekler. Cevap verdiği her bir Client bağlantısı için ayrı birer kanal oluşturur. Daha sonradan ilgili olaylar kanalın içeriği ile beraber tetiklenir.

Kanalların Rolleri

Indy server’ları, kanallar etrafında dizayn edilmiştir ve Unix server’ların çalışma mantığına yakındır. Yanlız Unix uygulamaları tipik olarak ya hiç soyutlama katmanı olmadan ya da az miktarda soyutlama katmanı ile direk olarak stack ile yüz yüze gelir. Indy ise, programcıyı stack ile uğraşma karmaşasından soyutlayarak, detayları otomatik ve şeffaf bir şekilde kendi içinde tanımlar.

Genelde Unix server’ları, client’lardan gelen istekleri izleyen bir ya da bir kaç dinleyici işleme sahiptir. Dinleyici işlemin kabul ettiği her client isteği, server tarafından yeni bir fork işlemine alınır. Her bir işlem bir client ile ilgili olduğu için, server birden çok client bağlantısını çok kolay bir şekilde tutabilmektedir. Tabi ki her işlem, kendi güvenlik kapsamında çalışmaktadır.

Indy serverları da benzer biçimde işlemleri gerçekleştirir. Unix’in aksine, Windows fork’lar ile iş görmez. Bunun yerine benzer ama aynı olmayan kanalları işler. Unix’in bir iş ayırmasının aksine Indy server’ları, her bağlantı için ayrı bir kanal ayırır. Bu işlemlerin dezavantajından çok, hemen hemen tüm avantajlarını sağlar.

Yüzlerce Kanal

Çok meşgul bir server’da, binler belki onbinlerce kanal gerekebilir. Yaygın bir inanışa göre, kanlların fazlalığı sisteminizi öldürür. Ama bu yanlış bir tespittir.

Å?u an bile sisteminizde çalışan thread sayısı sizi şaşırtabilir. Mesela bazen olurki 300 adet kanal açık olduğunda işlemci ve hafıza kullanımı, 500 adet kanal açık olmasına göre daha fazla olabilir.

Çoğu server’lar kanallarda belli verileri beklemekle harcarlar. Bu kanalların mesela 500 tanesinin ancak 25-30 tanesi aktif olarak çalışıyorlardır. 500 tane kanal açık olması demek, 500′ünün de aynı anda çalıştığı manasına gelmez.

Socket uygulamalarında, yavaş çalışan ekipmanlar yüzünden bazı kısıtlamalar olmaktadır. Bu ekipmanlar birisi hiç şüphesiz ethernet kartlarıdır. Ver hiç bir şey ethernet kartının mevcut kapasitesinin üzerine çıkamaz. Hızlı bir ethernet dahi olsa, işlemcinin cevap verememesi gibi bir çok nedenden dolayı darboğazlar(bottleneck) yaşanabilir.

Gerçekçi Kanal Limitleri

Bir işlemin 1000′den fazla kanal oluşturmasını ortalama bir sistem, hafıza meselelerinden dolayı bir sorun olarak algılar. Kanalların stack boyutu düşürülerek kanal sayısı artırılabilir. Bununla birlikte bu noktada başka alternatifleri araştırmak gerekmektedir.

Çoğu server, olsa olsa bir kaç yüz kanala ihtiyacı olur. Ama yüksek seviye serverlar, daha fazlasına ihtiyacı olur ve bu yüzden farklı davranışlara yönelmelidir. Indy’yi kullanan serverlar böyle binlerce kanal oluşturan tiplerdendir.

Anlaşılması gereken diğer bir nokta ise, servera bağlı client sayısı, o an ki kanal sayısına eşit olmak zorunda değildir. Her client kendi özel kanalını ayırmasının yanında, client sadece bağlıyken bir kanal ayrılır. HTTP server gibi çoğu server servisinin bağlantısı kısa ömürlüdür. Web sayfaları için HTTP bağlantıları, sadece son bir saniye ya da daha azında işlem görür. Sadece 500 kanal ve her bağlantı başına 1 sn harcandığını farz edersek, saatde 30,000 client’a izin verir.

Indy 10, server kanallamasına ek olarak diğer modelleri de destekleyerek, bu ihtiyaçlara cevap veriyor. Indy 10, sadece kullanılarbilir hafıza kadar socketleri ayırabilir.

Server Modelleri

TCP Server oluşturabilmek için iki yol mevcuttur. Komut Denetleyicileri(Command Handlers) ve OnExecute olayı. Komut denetleyicileri server oluşturmayı çok kolaylaştırmaktadır, ama her duruma uygun değildir.

Komut denetleyicileri, yazı formatında komut alışverişi yapan protokoller için uygundur. Fakat binary yapıda komutları olan veya komutlar üzerine kurulu olmayan protokoller için uygun değildir. Çoğu protokol yazı tabanlıdır ve komut denetleyiciler kullanılabilir. Komut denetleyicileri tamamen opsiyoneldir. Kullanılmadığında, Indy serverları hala eski metod kullanımlarını destekler. Komut denetleyicilerini daha sonra ayrıntılı bir şekilde işleyeceğiz.

OnExecute Olayı

Bazı protokoller, binary komutlar içerir veya hiç komutları yoktur. Bu yüzden komut denetleyicileri için uygun değillerdir. Bu tip serverlar için OnExecute olayı kullanılmalıdır. OnExecute, bağlatı sürdürüldüğü müddetçe, tekrar tekrar meydana gelir. Å?imdi basit bir server tanımlamasını Indy 10 için görelim.

procedure TForm1.MyTCPServerExecute(AContext: TIdContext);
var
  Command: string;
begin
  with AContext.Connection.IOHandler do
  begin
    command := Trim(ReadLn);
    if command = 'CIKIS' then
    begin
      WriteLn('200 Good Bye');
      Disconnect;
    end
    else if command = 'SAATIN_KAC' then
    begin
      WriteLn('200 ' + TimeToStr(Time));
    end
    else
    begin
      WriteLn('400 Bilinmeyen komut');
    end;
  end;
end;

Indy 10′dan önceki versiyonlarda, OnExecute olayının parametresi AContext değil AThread‘dir. Ve WriteLn, ReadLn gibi komutlar, önceki makaleden de hatırlayacağınız gibi, IOHandler içinde değil direk olarak TIdConnection içindedir. Yani Indy 10 için yazdığımız yukarıdaki with bloğunu şöyle yazmalıyız:

with AThread.Connection do

Uygun bir bağlantı olup olmadığını test etmemize gerek yoktur. Çünkü Indy bunu otomatik olarak yapmaktadır. Ayrıca herhangibir döngü de yapmanıza gerek yoktur, çünkü bunu da Indy sizin yerinize yapar. Bu olay tekrar tekrar çalıştırılır, ta ki bağlantı var olmayana kadar. Buna sebep olan yukarıda ‘CIKIS’ komutunda olduğu gibi ne harici bir bağlantı kesilmesidir, ne bir network hatasıdır, ne de client’ın bağlantıyı kesmesidir. Gerçekte, Indy’nin bağlantı kesme denetimi ile müdahale edilmesiyle hiçbir döngü yapılmaz hale gelecektir.

Komut Denetleyicileri (Command Handlers)

Indy 9.0 ile birlikte gelen bu özellik, TCP server tanımlamalarını çok kolaylaştırmıştır. Komut denetleyicilerini, server’ın "Action List"’i olarak görebilirsiniz. Her bir komut için komut denetleyicisi tanımladıktan sonra, bu komut denetleyicisinin davranışını ve de cevabını da belirtmelisiniz. Client tarafından bir komut geldiği vakit, server bu komutu ayrıştırır ve bağlı olan komut denetleyicisine yollar. Komut denetleyicilerinde sadece davranışlarını düzenleyebileceğiniz özellikler yoktur. Ayrıca metodlar ve olaylar da bulunmaktadır.

Önceden de bahsettiğimiz gibi komut denetleyicileri sadece yazı tabanlı komut ve cevaplara sahip TCP protokollerinde iş görür. Bununla birlikte, günümüzde kullanılan protokollerin %95′i bu şekildedir. Komut denetleyicileri binary verilerle uğraşabilirken, sadece yazı tabanlı komutlarla uğraşabilir.

Indy 9′da TIdTCPServer‘da mevcut olan CommandHandlers özelliği, Indy 10 ile birlikte artık TIdCmdTCPServer sınıfına alınmıştır. Yani eğer komut denetleyicilerini kullanmak istiyorsanız, TIdTCPServer yerine TIdCmdTCPServer bileşenini kullanmalısınız. Yine Indy 9′da CommandHandlersEnabled isminde bir özellik mevcuttur. Eğer bu özellik True ise, öncelik komut denetleyicilerinde olacaktır. Yani OnExecute olayı olsa bile, bu özellik True olduğunda ilgili komut denetleyicisi çalıştırılacaktır, OnExecute çalıştırılmayacaktır. Ama komut denetleyicisi ya aktif değil ya da bilinmeyen bir komut ise OnExecute çalıştırılır. Indy 10′da komut denetleyicileri ayrı bir bileşene taşındığından bu özelliği gerek kalmamıştır.

Å?imdi şöyle bir örnek yapalım. Üç adet komutumuz olsun:

• TarihGoster: Server’ın tarihini göstersin.
• Yardim: Mevcut komutları göstersin.
• Cikis: Oturumu kapatsın ve bağlantıyı kapatsın.

Bu basit tanımlama için yeni bir uygulama oluşturalım. Foruma bir adet TIdCmdTCPServer yerleştirelim. DefaultPort olarak herhangi bir şey girebilirsiniz. Örneğimizde 8500 gibi bir port kullanalım. Active özelliğini True yapalım, böylece uygulama çalışır çalışmaz TCP server çalışmaya başlayacak.

Bileşenin CommandHandlers özelliğine çift tıklayalım. Açılan özellik editöründen yeni bir komut denetleyicisi ekleyelim. Oluşturduğumuz yeni denetleyiciyi seçtikten sonra Object Inspector’dan özelliklerini değiştirebilirsiniz. Command özelliğini Cikis olarak değiştirelim. Eğer server’ı sadece sizin yapacağınız program kullanacaksa ve sistem her zaman Türkçe karakterleri tanıyabilecek nitelikte olacaksa, Command kısmına Türkçe karakter girebilirsiniz. Sonuçta bu da bir stringdir. Ama aksi durumda sorun çıkarmaması için Türkçe karakterden kaçınmalısınız.

Disconnect özelliğini True yapalım. Böylece bu komut çalıştığında oturum kapatılacak ve client ile bağlantı kesilecektir. Name özelliğini bu örneğimiz için cmdCikis olarak değiştirelim. NormalReply altından Code kısmına 200, Text kısmına "Gule gule" yazalım. Komutlar genelde, 3 haneli bir sayı ve isteğe bağlı bir yazıdan oluşur. Eğer hata oluşmazsa, komutun normal cevabı bu girdiğimiz code ve text olacaktır.

Bu şekilde çalışabilecek bir komut denetleyicisi oluşturmuş olduk.

Å?imdi bu komutumuzu test edelim. Derleyip programı çalıştırdıktan sonra, komut satırından "telnet 127.0.0.1 8500" şeklinde girelim. Karşımıza "200 Welcome" gibi bir yazı çıktı ise başarılı bir şekilde bağlanmışız demektir. Ardından az önce eklediğimiz Cikis komutunu yazalım ve entere basalım. Gelen cevap NormalReply kısmına yazdığımız text ve code’dur. Tekrar telnet ile bağlantı kurup Cikis dışında bir şey girdiğinizde "400 Unknown Command" gibi bir cevap ile karşılaşırsınız.

Tebrikler ilk komut denetleyici tabanlı tcp server’ınızı oluşturdunuz. Å?imdi dilerseniz Yardim ve TarihGoster komutlarına da el atalım.

Cikis komutunu tanımladığımız gibi Yardim komutunu da tanımlayalım. Tek fark olarak, Disconnect özelliği False olmalıki, bu komut çalıştıktan sonra bağlantımız kesilmesin. NormalReply.Text özelliği StringList özellik editörünü kullandığı için bibr Memo’nun ya da ListBox’ın içeriğini doldurur gibi komut yardım bilgilerini yazabilirsiniz.

TarihGoster’i de Yardim komutu gibi tanımlıyoruz. Tek fark, NormalReply.Text özelliğini tanımlamıyoruz. Ama Code‘u yine 200 yapalım. TarihGoster komut denetleyicisi seçili iken Object Inspector’dan yeni bir event ekleyelim. OnCommand event’ına gelip çift tıklayalım. Eğer TIdCommand bulunamadı gibi bir hata alırsanız uses kısmına IdCommandHandlers‘ı ekleyebilirsiniz. Event Handler’ımızın içeriğini aşağıdaki gibi dolduralım

procedure TForm1.IdTCPServer1TIdCommandHandler2Command(ASender: TIdCommand);
var
  DateFormat: string;
begin
  if ASender.Params.Count = 0 then
  begin
    DateFormat:= 'yyyy-mm-dd hh:nn:ss';
  end
  else
  begin
    DateFormat:= ASender.Params[0];
  end;
  ASender.Reply.Text.Text := FormatDateTime(DateFormat, Now);
end;

Eğer komutumuzda ekstradan bir parametre yoksa kendimiz bir tarih formatı belirliyoruz. Aksi halde client’ın gönderdiği ilk parametreyi tarih formatı olarak kullanıyoruz. Ardından cevabımızı "Text" StringList’inin içine yerleştiriyoruz.

Fatih Tolga Ata © 2007

Kaynaklar:

• Indy 10 Yardım Dosyaları
• IndyProject Makaleleri
• Atozed Indy Makaleleri
• Indy In Depth

Bölüm 1 – Giriş

Bölüm 2 – Okuma ve Yazma

Bölüm 3 – Server