indy 10 , TidTCPClient Hakkında
Forum kuralları
Forum kurallarını okuyup, uyunuz!
Forum kurallarını okuyup, uyunuz!
indy 10 , TidTCPClient Hakkında
Merhaba Değerli Üyeler ,
Socket programlama ile deneyimim olmadı, şöyle bir şey sormak istiyorum , TidTCPServer.Execute metodu ile bağlanan TCPClient lardan gelen mesajları alabiliyorum, AContext leri bir listeye depoluyorum sonra bu listedeki canlı bağlantılara mesaj gönderiyorum WriteLN ile, ilgili TCPClient tan ReadLN dediğimde okuyabiliyorum fakat şunu sormak istiyorum TCPServerde olduğu gibi, TCPClient ta kendisine bir cevap dönüldüğünde tetiklenen bir metoda sahip mi? yoksa sürekli timer yada vb bir mekanizma ile servera sorması mı gerekiyor, eğer böyleyse 50-100 bağlantının servere sürekli dönüş varmı gibi bir sorgu yapması sistemi olumsuz etkilemez mi?
Socket programlama ile deneyimim olmadı, şöyle bir şey sormak istiyorum , TidTCPServer.Execute metodu ile bağlanan TCPClient lardan gelen mesajları alabiliyorum, AContext leri bir listeye depoluyorum sonra bu listedeki canlı bağlantılara mesaj gönderiyorum WriteLN ile, ilgili TCPClient tan ReadLN dediğimde okuyabiliyorum fakat şunu sormak istiyorum TCPServerde olduğu gibi, TCPClient ta kendisine bir cevap dönüldüğünde tetiklenen bir metoda sahip mi? yoksa sürekli timer yada vb bir mekanizma ile servera sorması mı gerekiyor, eğer böyleyse 50-100 bağlantının servere sürekli dönüş varmı gibi bir sorgu yapması sistemi olumsuz etkilemez mi?
Volkan KAMADAN
www.polisoft.com.tr
www.polisoft.com.tr
Re: indy 10 , TidTCPClient Hakkında
Ben Indy 9 kulanıyorum:
Dediğiniz gibi timer yada thread kullanmanız gerekiyor ama sürekli server'a mesaj göndermeniz gerekmez. Sadece sürekli olarak ReadBuffer'ı (yada Readln vs) kullanıp mesaj gelip gelmediğini kontrol etmelisiniz
Dediğiniz gibi timer yada thread kullanmanız gerekiyor ama sürekli server'a mesaj göndermeniz gerekmez. Sadece sürekli olarak ReadBuffer'ı (yada Readln vs) kullanıp mesaj gelip gelmediğini kontrol etmelisiniz
There's no place like 127.0.0.1
Re: indy 10 , TidTCPClient Hakkında
Cevabınız için teşekkür ederim ,
Belirttiğim gibi yabancı olduğum bir konuydu, Readln vb komutların sunucuya gidip geldiği yanılgısına düştüm, dediğinizden anladığım kadarıyla sunucudan cliente gönderilen veri o an zaten cliente gelmiş oluyor ama hali hazırda bir event yayınlanmadığından anlamak için bizim kontrol etmemiz gerekiyor ReadLn gelmiş veri içinde çalışıyor tamam performans sorunu olmayacağını anlamış oldum, peki sunucuda ki geçerli bağlantılara nasıl ulaşabilirim ? Execute olayında AContext i diziye atıyorum orada birikiyorlar PeerIP den mükerrerlik kontrolünü yapıp var olanı tekrar listeye almıyorum, peki bu Context lerin bağlantılarının halen canlı olup olmadıklarını nasıl anlarım, clientler bilinçli olarak bağlantı kapatılarken sorun yok bir mesaj gönderirim ben kapanıyorum vb listeden düşürürm, ama istem dışı olan kopukluklarda sıkıntı çıkabilir, özetle canlı Context lerin listesi bir yerde duruyor mu? son olarak bir client servere bğalantdıktan sonra hiç veri alış verişi ypamadan nekadar süre canlılığını korur, ping vb işlere girmek gerekir mi?
Belirttiğim gibi yabancı olduğum bir konuydu, Readln vb komutların sunucuya gidip geldiği yanılgısına düştüm, dediğinizden anladığım kadarıyla sunucudan cliente gönderilen veri o an zaten cliente gelmiş oluyor ama hali hazırda bir event yayınlanmadığından anlamak için bizim kontrol etmemiz gerekiyor ReadLn gelmiş veri içinde çalışıyor tamam performans sorunu olmayacağını anlamış oldum, peki sunucuda ki geçerli bağlantılara nasıl ulaşabilirim ? Execute olayında AContext i diziye atıyorum orada birikiyorlar PeerIP den mükerrerlik kontrolünü yapıp var olanı tekrar listeye almıyorum, peki bu Context lerin bağlantılarının halen canlı olup olmadıklarını nasıl anlarım, clientler bilinçli olarak bağlantı kapatılarken sorun yok bir mesaj gönderirim ben kapanıyorum vb listeden düşürürm, ama istem dışı olan kopukluklarda sıkıntı çıkabilir, özetle canlı Context lerin listesi bir yerde duruyor mu? son olarak bir client servere bğalantdıktan sonra hiç veri alış verişi ypamadan nekadar süre canlılığını korur, ping vb işlere girmek gerekir mi?
Volkan KAMADAN
www.polisoft.com.tr
www.polisoft.com.tr
Re: indy 10 , TidTCPClient Hakkında
Sizin de dediğiniz gibi bağlı olan client'ların listesini sizin tutmanız gerekiyor.
Client'ların hala bağlı olup olmadığının kontrolü içinse Indy 10'da bulunan TIdSocketHandle.SetKeepAliveValues() ' kullanabilirsiniz.
Client'ların hala bağlı olup olmadığının kontrolü içinse Indy 10'da bulunan TIdSocketHandle.SetKeepAliveValues() ' kullanabilirsiniz.
There's no place like 127.0.0.1
Re: indy 10 , TidTCPClient Hakkında
@SimaWB , bilgiler için çok teşekkür ederim.
İyi çalışmalar.
İyi çalışmalar.
Volkan KAMADAN
www.polisoft.com.tr
www.polisoft.com.tr
Re: indy 10 , TidTCPClient Hakkında
konu ile baglantisi oldugu icin, yeni bir baslik acmak istemedim.
arkadaslar, okudugum bir makaleye göre tek islemcili bir bilgisayar üzerinde process basina öngörülen ve tavsiye edilen Thread sayisi 16.
Indy bilesenleri Multithread olduguna ve kullanici sayisi (teorik olarak) sinirsiz olduguna göre, TidTcpServer kullanici sayisi kadar Thread olusturuyor.
Peki, process basina MaxThreadCount 16 ise, Multithread socketler bu isi nasil yapiyorlar?
yine internette buldugum bir yaziya göre, islemci her bir Thread icin 20 mili saniye gibi bir zaman veriyor.
Her bir Thread 20 mili saniye süre ile islem yapabiliyor ise, icerisinde 100K Thread bulunduran bir socket gönderdigimiz yaziyi yaklasik 5 dakika icerisinde isleme sokup hedefe ulastirmasi gerekiyor.
oysa ki, gönderdiginiz veri anlik ileti olarak karsiya yansiyor.
peki bu 20 milisaniyede anlatilmak istenen ne dir?
simdiden tesekkür ederim...
arkadaslar, okudugum bir makaleye göre tek islemcili bir bilgisayar üzerinde process basina öngörülen ve tavsiye edilen Thread sayisi 16.
Indy bilesenleri Multithread olduguna ve kullanici sayisi (teorik olarak) sinirsiz olduguna göre, TidTcpServer kullanici sayisi kadar Thread olusturuyor.
Peki, process basina MaxThreadCount 16 ise, Multithread socketler bu isi nasil yapiyorlar?
yine internette buldugum bir yaziya göre, islemci her bir Thread icin 20 mili saniye gibi bir zaman veriyor.
Her bir Thread 20 mili saniye süre ile islem yapabiliyor ise, icerisinde 100K Thread bulunduran bir socket gönderdigimiz yaziyi yaklasik 5 dakika icerisinde isleme sokup hedefe ulastirmasi gerekiyor.
oysa ki, gönderdiginiz veri anlik ileti olarak karsiya yansiyor.
peki bu 20 milisaniyede anlatilmak istenen ne dir?
simdiden tesekkür ederim...
kıdemsiz üye
Re: indy 10 , TidTCPClient Hakkında
Bence Tuğrul Helvacı'nın 3 bölümden oluşan Derinlemesine Threading makaleleri thread konusundaki en güzel Türkçe kaynak.
Okumayanlara okumalarını şiddetle tavsiye ederim.
Sizin için yeterli olurmu bilmem ama sorduğunuz konuda da bilgi var.
Okumayanlara okumalarını şiddetle tavsiye ederim.
Sizin için yeterli olurmu bilmem ama sorduğunuz konuda da bilgi var.
There's no place like 127.0.0.1
Re: indy 10 , TidTCPClient Hakkında
Oncelikle vakit ayirdigin icin cok tesekkur ederim.
Fakat aklima takilan sorularin cevaplarini malesef bu iki makalede bulamadim.
Ozellikle bilmek istedigim nokta, binlerce threadi bir process icerisinde ve akici olarak calistiran socketlerin bu islemi nasil basardiklari. Yaptiklari islemler oyle kucuk donguler degil. Hem binlerce thread, hemde es zamanli binlerce data transferi.
Bu isin mutlaka bir yolu olmasi gerek.
Fakat aklima takilan sorularin cevaplarini malesef bu iki makalede bulamadim.
Ozellikle bilmek istedigim nokta, binlerce threadi bir process icerisinde ve akici olarak calistiran socketlerin bu islemi nasil basardiklari. Yaptiklari islemler oyle kucuk donguler degil. Hem binlerce thread, hemde es zamanli binlerce data transferi.
Bu isin mutlaka bir yolu olmasi gerek.
kıdemsiz üye
Re: indy 10 , TidTCPClient Hakkında
arkadaslar hala bir sonuca ulasabilmis degilim.
okumadigim makale kalmadi.
okumadigim makale kalmadi.

kıdemsiz üye
Re: indy 10 , TidTCPClient Hakkında
20ms olayını sorduğunuzu varsayıyorum. Bu süre her bir işleç'in çalıştırılmas süresidir. Bu süre sonunda eğer kuyrukta bekleyen işleç varsa 20ms o çalıştırılır, sonra diğeri. Bu şekilde sistem devam eder. Eğer çok çekirdekli bir sistemdeyseniz ve işleç sayısı azsa, işleçleriniz sürekli çalışacaktır. Network kartlarının buffer özelliği vardır, siz veriyi gönderdiğinizde yada aldığınızda bunlar bufferda bekleyecektir. Buffer dolduğunda kart paketi red eder, paket tekrar gönderilir.
process başına 16 thread tavsiye edilen bir değer sanırım sadece. Daha fazlasını da kullanabilirsiniz. Windows üzerinde zaten TCP/IP bağlantı sayısı 300 ile sınırlıydı diye hatırlıyorum, bunu artırmak için registry'den ayarlama yapmak gerekiyordu. XP'de dll bile patchleniyordu. IRC gibi kendi protkolünüzü geliştirirseniz fazlaca thread kullanmanıza gerek kalmayabilir.
Aklıma gelenleri yazdım, tam olarak neye çözüm aradığınızı bilemediğimden.
process başına 16 thread tavsiye edilen bir değer sanırım sadece. Daha fazlasını da kullanabilirsiniz. Windows üzerinde zaten TCP/IP bağlantı sayısı 300 ile sınırlıydı diye hatırlıyorum, bunu artırmak için registry'den ayarlama yapmak gerekiyordu. XP'de dll bile patchleniyordu. IRC gibi kendi protkolünüzü geliştirirseniz fazlaca thread kullanmanıza gerek kalmayabilir.
Aklıma gelenleri yazdım, tam olarak neye çözüm aradığınızı bilemediğimden.
Re: indy 10 , TidTCPClient Hakkında
Hocam cevabin icin tesekkur ederim.
Sanirim bu isten anlamam gereken su. Indynin tcpserver bileseninde aslinda her bir baglanti icin yeni bir thread olusturulmuyor. Olusturulan toplam thread sayisi 16 ve bu 16 thread tum socketlerin islemlerini sirasi ile execute yapiyor.
Oyle ise neden internetin her kosesinde her client icin bir thread olusturuluyor yaziyor? Yada hakikaten her client icin bir thread olusturuluyorsa 10000 baglanti icin yine 10000 thread olusturuluyor demektir ki, bu cizilen 16 sinirini cok fazla asiyor demektir. Ustelik her 20 mili saniyede bir thread devreye giriyor ve islemini execute yapabilmesi icin isletim sisteminden token aliyorsa, 100 bin baglantida bir baglantinin veri gonderme icin bekleyis suresi 5 dakikanin uzerinde bir zaman gerektirir. Oysa ki, pratikte bu boyle degil. Siz veriyi gonderirsiniz, veri sanki anlik iletiymis gibi bekleme suresini size fark ettirmeden karsiya ulastirir. Her iki olay birbirlerine tezat.
Icinden cikamadigim iki konu bundan ibaret. Birincisi zamanlama, ikincisi thread sayisi yada limiti.
Sanirim bu isten anlamam gereken su. Indynin tcpserver bileseninde aslinda her bir baglanti icin yeni bir thread olusturulmuyor. Olusturulan toplam thread sayisi 16 ve bu 16 thread tum socketlerin islemlerini sirasi ile execute yapiyor.
Oyle ise neden internetin her kosesinde her client icin bir thread olusturuluyor yaziyor? Yada hakikaten her client icin bir thread olusturuluyorsa 10000 baglanti icin yine 10000 thread olusturuluyor demektir ki, bu cizilen 16 sinirini cok fazla asiyor demektir. Ustelik her 20 mili saniyede bir thread devreye giriyor ve islemini execute yapabilmesi icin isletim sisteminden token aliyorsa, 100 bin baglantida bir baglantinin veri gonderme icin bekleyis suresi 5 dakikanin uzerinde bir zaman gerektirir. Oysa ki, pratikte bu boyle degil. Siz veriyi gonderirsiniz, veri sanki anlik iletiymis gibi bekleme suresini size fark ettirmeden karsiya ulastirir. Her iki olay birbirlerine tezat.
Icinden cikamadigim iki konu bundan ibaret. Birincisi zamanlama, ikincisi thread sayisi yada limiti.
kıdemsiz üye
Re: indy 10 , TidTCPClient Hakkında
Her işleç'in 20ms'den fazla sürdüğünü varsayıyorsunuz. Bir çok işleç o sürede sonlanıyor olabilir.
Ben daha önce delphide olmasada başka bir dilde Server/Client bir uygulamaya yazmıştım. Her client için bir thread oluşturmadım. Bu ancak her client'ı başka bir porta aldığınız durumlarda geçerli olabilir. Tüm clientları tek port üzerinden bağlamanız mümkün. Neden her birine ayrı port açasınız ki?
100 bin gibi bir client sayısı vermişsiniz ancak web serverlar bile bu kadar client'a hizmet vermiyor. Load balancing yapılarak paralel serverlar kullanılıyor, iş yükü bu serverlar arasında dağıtılıyor. Mesala IIS (internet information service) varsayılan olarak 200 kullanıcı ile çalışıyor. Aynı anda 200 kullanıcıya hizmet veriyor, yani 5 saniye önce istekte bulunan kullanıcı sayılmıyor. Şöyle anlatayım;
client server'a komut gönderiyor, server işlemler yaparak 3ms'de çevap veriyor olsun. Server cevap verdikten sonra (paketi ilettikten sonra) o bağlantıyı kapatacaktır. 3ms içinde 200 client server'a paket gönderirse limite ulaşılmış oluyor. Bu rakama ulaşmak çoğu sistem için mümkün değil, çünkü 30 saniyelik timeout süresi var birde. Client istek gönderdiğinde bu istek 30 saniye boyunca bekleyecektir. 30 saniye içinde server'a ulaşamazsa o zaman red cevabı döner.
Ben daha önce delphide olmasada başka bir dilde Server/Client bir uygulamaya yazmıştım. Her client için bir thread oluşturmadım. Bu ancak her client'ı başka bir porta aldığınız durumlarda geçerli olabilir. Tüm clientları tek port üzerinden bağlamanız mümkün. Neden her birine ayrı port açasınız ki?
100 bin gibi bir client sayısı vermişsiniz ancak web serverlar bile bu kadar client'a hizmet vermiyor. Load balancing yapılarak paralel serverlar kullanılıyor, iş yükü bu serverlar arasında dağıtılıyor. Mesala IIS (internet information service) varsayılan olarak 200 kullanıcı ile çalışıyor. Aynı anda 200 kullanıcıya hizmet veriyor, yani 5 saniye önce istekte bulunan kullanıcı sayılmıyor. Şöyle anlatayım;
client server'a komut gönderiyor, server işlemler yaparak 3ms'de çevap veriyor olsun. Server cevap verdikten sonra (paketi ilettikten sonra) o bağlantıyı kapatacaktır. 3ms içinde 200 client server'a paket gönderirse limite ulaşılmış oluyor. Bu rakama ulaşmak çoğu sistem için mümkün değil, çünkü 30 saniyelik timeout süresi var birde. Client istek gönderdiğinde bu istek 30 saniye boyunca bekleyecektir. 30 saniye içinde server'a ulaşamazsa o zaman red cevabı döner.
Re: indy 10 , TidTCPClient Hakkında
bir yanlis anlasilma var sanirim.
ben port acmaktan bahsetmedim hocam. ayni port üzerindeki baglanti sayisindan bahsettim.
sizin verdiginiz webserver örneginde tabiiki haklisiniz. fakat benim yapmak istedigim client/server... yani webserver, webservice degil.
ayni msn'de yada icq'da oldugu gibi sürekli bagli durumda olan socketlerin isteklerini execute etmek istiyorum.
yük dagilimindan bahsetmissiniz. her 200 kullanici icin arti bir server maliyetleri yükseltir. ki, icq yada msn gibi sirketlerin her 200 kullanici icin bir server kullandiklarini sanmiyorum.
en azindan 50000 kullanicinin isteklerine tek bir server üzerinden yanit verebilmek gerekli. aksi taktirde 100 milyon kullanicisi olan bir msn'in yada icq'nun server sayisini ve bu serverlerin giderlerinin firmaya ne denli zarar olusturabilecegini tahmin etmek cok zor olmayacaktir.
bunun bir yolu olmali. Mübala olmasin, bir dünya makale okudum. hem türkce, hem almanca. fakat hic bir yerde tatmin edici bir cevap bulamadim.
ben port acmaktan bahsetmedim hocam. ayni port üzerindeki baglanti sayisindan bahsettim.
sizin verdiginiz webserver örneginde tabiiki haklisiniz. fakat benim yapmak istedigim client/server... yani webserver, webservice degil.
ayni msn'de yada icq'da oldugu gibi sürekli bagli durumda olan socketlerin isteklerini execute etmek istiyorum.
yük dagilimindan bahsetmissiniz. her 200 kullanici icin arti bir server maliyetleri yükseltir. ki, icq yada msn gibi sirketlerin her 200 kullanici icin bir server kullandiklarini sanmiyorum.
en azindan 50000 kullanicinin isteklerine tek bir server üzerinden yanit verebilmek gerekli. aksi taktirde 100 milyon kullanicisi olan bir msn'in yada icq'nun server sayisini ve bu serverlerin giderlerinin firmaya ne denli zarar olusturabilecegini tahmin etmek cok zor olmayacaktir.
bunun bir yolu olmali. Mübala olmasin, bir dünya makale okudum. hem türkce, hem almanca. fakat hic bir yerde tatmin edici bir cevap bulamadim.
kıdemsiz üye
Re: indy 10 , TidTCPClient Hakkında
bağlantıyı su borusu yada elektrik hattı gibi düşünüyorsunuz ama öyle değil.. MSN/ICQ gibi bir program yazsanız bile sürekli bağlı kalmak nedir ki? Böyle birşey zaten yok. Client/Server sürekli haberleşmez, bu size kalmış bir durum tamamen. Belli aralıklarla Server ve Client haberleşerek hala orada olup olmadıklarını kontrol ederler. Sonuçta elinizde veri paketleri ve bir veri yolu var. Sürekli paket gönderemzsiniz, paketler kesiklidir ve tek kanaldan gidebilir. Yani tek port üzerinden. webservis ile webserver arasında teknik olarak çok bir fak yok çünkü ikiside gelen paketleri işleyip cevap veriyor. Sadece protolleri farklı.
Hala ne yapmak istediğinizi anlamış değilim. ICQ kurmaksa amacınız, binlerce kullanıcıyı basit bir serverda bile tutabilirsiniz çünkü hepsi tek port üzerinden haberleşebilir. her kullanıcıya thread açamıza gerek yok. Paket yapısını hesaba katmıyorsunuz gibi geliyor bana. IP kullanarak kullanıcıları eşleştreceğinizi mi düşünüyorsunuz?
Hala ne yapmak istediğinizi anlamış değilim. ICQ kurmaksa amacınız, binlerce kullanıcıyı basit bir serverda bile tutabilirsiniz çünkü hepsi tek port üzerinden haberleşebilir. her kullanıcıya thread açamıza gerek yok. Paket yapısını hesaba katmıyorsunuz gibi geliyor bana. IP kullanarak kullanıcıları eşleştreceğinizi mi düşünüyorsunuz?
Re: indy 10 , TidTCPClient Hakkında
bir nevi kendi protokolümü yazmak istiyorum. su an emekleme asamasindayim. arastirmalar yapiyorum. aklimdaki tüm sorulara cevap bulduktan sonra bu birikimi pratige dökecegim insaAllah.
kismet olursa es zamanli olarak ayni socket üzerinden hem clientler arasindaki yazismayi, hemde veritabani sorgusundan dönen stream'lari gönderecegim.
kücük capli ama genisletilebilinir bir msn yada icq protokolü gibi düsünelim.
yapmak istedigim bu. fakat isin multithread kismini kafam almiyor.
kismet olursa es zamanli olarak ayni socket üzerinden hem clientler arasindaki yazismayi, hemde veritabani sorgusundan dönen stream'lari gönderecegim.
kücük capli ama genisletilebilinir bir msn yada icq protokolü gibi düsünelim.
yapmak istedigim bu. fakat isin multithread kismini kafam almiyor.
kıdemsiz üye