Üye Girişi
Bağlan Google+ ile Bağlan Facebook ile Bağlan
Yeni Kayıt
Tüm Forumlar
  • Tüm Forumlar
  • Web Tasarım - Programlama
  • Yazılım Geliştirme
  • Delphi / C++ /Vb
  • Bu Konuda
Şimdi Ara

TCP Server

Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Daha Fazla
Bu Konudaki Kullanıcılar: Daha Az
2 Misafir (1 Mobil) - 1 Masaüstü, 1 Mobil
5 sn
10
Cevap
1
Favori
1.199
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
Konuya Özel
0 oy
Öne Çıkar
Cevapla
Sayfa: 1
Giriş
Mesaj
  • Merhaba,

    Sorum şu ki:
    TCP üzerinden işleyecek olan haberleşmenin Client'ından Server'a giden istekde, Request'in şu olduğunu varsayalım: 

     
      <requestcode>123</requestcode> 
      <params> 
              <param> 
                      <paramName>userName</paramName> 
                      <paramValue>admin</paramValue> 
              </param> 
              <param> 
                      <paramName>password</paramName> 
                      <paramValue>asdfgh12345</paramValue> 
              </param> 
      </params>


    (Formatlamaya takılmayalım lütfen, biliyorum, kötü) Burada "admin" yerine şifrelenmiş "admin" i (veya şifrenin şifrelenmiş hali olsun atıyorum) koymak mı daha mantıklı, yoksa tüm bu string'i şifreleyip göndermek mi daha mantıklı?

    Detay

    Küçük bir amatör iş için TCP üzerinden birkaç işlem yapacak bir server yazmayla uğraşıyorum, C# kullanarak. Şu ana kadar birşeyler geliştirmiş durumdayım. Server'ımı Request-Response mantığıyla (terim adı varsa bilmiyorum, başka bir mantıkda çalışan server tipi var mı onu da bilmiyorum) işletmek istiyorum. Gerekli sistemi kurduğumu düşünüyorum. Henüz Unit-Test vb. bir Test yöntemi ile test etme şansım olmadı (baştan girişmediğim için üşendim), tam ismini bilmediğim ama herkesin amatörken yaptığı şekilde (console application üzerinden debugger vasıtasıyla)

    Şimdiye kadar Request ve Response'u şu mantık üzerine kurdum;
    Request -> int RequestCode ve Parameter obje kolleksiyonu barındıran bir sınıf.
    Parameter ise bir Dictionary'nin bir elemanı gibi Name ve Value'dan oluşuyor.

    Şimdi karşıma şöyle bir sorun geldi (sorun demiyeyim de daha önce karşılaşmadığım için "en iyi" çözüm yolunu bilmediğim bir ayrım diyeyim):

    Ben şuanda şifrelemek istediğim verileri (Request veya Response için) Parameter objesi oluştururken, Value'ya şifreleyip atıyorum, byte array'inden string'e dönüştürüp Request nesnesi oluşturup, onu da Serialize edip TCP üzerinden Server'a (Client için) veya Response'u Client'a gönderiyorum. XML'den vazgeçmemin nedeni de buydu, Şifrelenmiş bir metni string'e dönüştürüp, ondan XML oluşturmaya çalıştığımda karakter hataları alıyorum (her zaman değil, kontrol karakteri denk gelirse (?)).

    Ama farkettim ki, aslında Parameter sınıfının Value'sunu Serializable herhangi bir obje yapabilirim, daha sonra Parameter koleksiyonunu da bir şekilde serialize edebilirdim (tahmin ediyorum ki Serializable olan bir sınıfın list'i otomatik olarak serializable olmuyor ? sonuçta list serializable değil ?), en son Request veya Response'u da serialize eder, tüm veriyi şifreler TCP üzerinden gönderebilirim. Sorumu tekrarlayayım:

    Göndereceğim tüm veriyi şifreleyip göndermem mi daha mantıklı? Yoksa göndereceğim verinin yalnızca şifrelenmesini istediğim kısmını şifrelemem mi daha mantıklı?

    Teşekkürler,
    İyi forumlar.







  • welrocken W kullanıcısına yanıt
    Ben kendi yazdığım kendime has TCP protokollerinde mümkün olabilecek herşeyi şifreliyorum.

    O kadar ki; bunlara "Request Code" diye tabir ettiğin kodlar ve mesajın/pakedin toplam byte olarak uzunluğu ve paket numarası da dahil. Hatta ve hatta şifrenin içerisine aynı zamanda mesajın yolda bozulup bozulmadığını test edebileyim diye mesajın SHA256 hashini de kattıktan sonra bir de üstüne üstlük mesaj ziplendiğinde daha da kısalmışsa zipli halini yolluyorum. Elbette tüm bu hadisenin çalışabilmesi için her mesajın önceden belirlenmiş/icat edilmiş sabit uzunluğa sahip bir "protokol başlığı"/header" gibi bir içeriğe sahip olması gerekiyor. Ekstra string verileri yine belirlenmiş bir şekilde bu başlığın arkasına eklenerek karşı tarafa yollanabilinir.

    Dolayısıyla Admin ve password de herhangi bir tarafa giden ister nümerik ister string bir bilgi/data olacağı için şifrelenmemesi için herhangi bir sebep göremiyorum.

    TCP programlama çok keyiflidir. Başarılar diliyorum.



    < Bu mesaj bu kişi tarafından değiştirildi Buzz Lightyear -- 7 Eylül 2015; 4:18:55 >




  • welrocken W kullanıcısına yanıt
    Karakter hataları almaktan bahsetmişsin.

    Byte Array'den stringe çevirme, ordan serialize edip yollama ve sonra tekrar karşı tarafta "Deserialize" olduğunda yanlış yorumlanıyor mesaj oralarda bir enayilik oluyor demek ki. XML formatıyla senin protokolün bazı durumlarda tam manasıyla ayrıştırılamıyor. Bu tip kodları her durumda çalışabilecek "Fool Proof" hale getirebilecek bir protokol lazım belli ki. Ama zaten sen de onun farkında olup stratejiyi değiştirmişsin.
    Birde TCP en ham şekliyle "stream" protokolü olduğu için çoğu kez her yollanan mesajın byte olarak uzunluğunun da bilinmesi ve karşı tarafa yollanması lazım. Bu tarz uygulamalar senin programında var mı ? veya eğer kullanıyorsan, kullandığın TCP iletişim protokolü veya kütüphanesi ham TCP protokolü ile senin kendine has mesajın arasında köprü vazifesini kuracak mesaj byte uzunluğu, SHA256 kontrolü, zipleme gibi hadiseleri otomatikman üstleniyor mu ?




  • Buzz Lightyear B kullanıcısına yanıt
    Hocam TCP zaten verileri kontrol ediyor diye biliyorum yani guvenilir bir baglanti cesidi tekrar kontrol etmeye gerek var midir?
  • bersgurs kullanıcısına yanıt
    Vardır. Çok enteresan bir şekilde bazen veri integrasyonu ister mahsus birilerinin müdahalesiyle veya donanım, yazılım hataları yüzünden karşı tarafa çok nadir de olsa yanlış ulaşabiliyor. Bu durumda kendi pakedimiz içersinde aynı mesajın kendi hesapladığımız SHA256, MD5 veya CRC gibi bir "hash"inin olması ekstra güvenilirlik sağlıyor.
  • quote:

    Orijinalden alıntı: Buzz Lightyear

    Karakter hataları almaktan bahsetmişsin.

    Byte Array'den stringe çevirme, ordan serialize edip yollama ve sonra tekrar karşı tarafta "Deserialize" olduğunda yanlış yorumlanıyor mesaj oralarda bir enayilik oluyor demek ki. XML formatıyla senin protokolün bazı durumlarda tam manasıyla ayrıştırılamıyor. Bu tip kodları her durumda çalışabilecek "Fool Proof" hale getirebilecek bir protokol lazım belli ki. Ama zaten sen de onun farkında olup stratejiyi değiştirmişsin.
    Birde TCP en ham şekliyle "stream" protokolü olduğu için çoğu kez her yollanan mesajın byte olarak uzunluğunun da bilinmesi ve karşı tarafa yollanması lazım. Bu tarz uygulamalar senin programında var mı ? veya eğer kullanıyorsan, kullandığın TCP iletişim protokolü veya kütüphanesi ham TCP protokolü ile senin kendine has mesajın arasında köprü vazifesini kuracak mesaj byte uzunluğu, SHA256 kontrolü, zipleme gibi hadiseleri otomatikman üstleniyor mu ?

    Karakter hataları TCP olayını katmadan önce, Serialize ederken alıyordum.
    Protokoller hakkında aşırı bilgim yok, local network üzerindeki bir server'a kurulacak basit bir program yazmaya çalışıyorum. TCP'nin kendisinin neleri hallettiğini bilmiyorum, Server-Client arası bilgi alışverişi kısmını test etme şansım olmadı. Operation callarımı falan test ediyorum henüz. Ama boyutla ilgili birşey implement etmiş değilim. Hazır bir kod kullanıyorum orada (adamın biri yapmış ClientListener diye bir sınıf, 10025 buffer size koymuş, while(true) demiş try yapmış :)) oraya dalmadan önce şu şifreleme kısmını halledeyim dedim, operasyonlar felan komple çalışsın en son evde iki bilgisayar üzerinden test etmeyi düşünüyorum orayı. Çok sıkıntı olacağını sanmıyorum oraların, zira okulda bir dersin ödevi için veri aktarımının her aşamasını matlab üzerinden simüle etmiştik. (Protokol işin içine girmeden, teorik olarak, Compression Framing vs.)

    Yani dediğiniz gibi "Deserialize" yapmadım hiç. Daha doğrusu yaptım, ama XML kullanmadan yaptım, kendi yöntemim çalışıyor. Ama şöyle, gönderdiğim veriyi birisi görür de yan yana ASCII kullanıp birleştirirse, mesaj içeriğini görebilir ve bu şöyle bir sıkıntı oluşturabilir:

    Kullanıcı giriş yaptıktan sonra herhangi bir operasyon için çağrı yaparken, Request'i alırken SessionKey soruyorum (terim adı bu mudur bilmiyorum ben böyle salladım ama, bir kullanıcı giriş yaptığında, server tarafına giriş istediğinde bulunduğunda, credentials'ı onaylanırsa veritabanından, GUID'den yeni bir tane üretip veritabanında user'a online flag'i atıyorum ve GUID'ı oraya atıyorum, aynı zamanda user'a geri response atarken bu session key'i veriyorum. Daha sonra user'ın isteyeceği her request'in içinde bu sessionkey'i soruyorum, userName ve sessionKey eşleşirse request işleme gidiyor. Dolayısıyla mesaj paketini şifresiz halde gören biri, kullanıcının adını ve sesionkey'ini bilerek istediği işlemleri yapabilir. Bilmiyorum izlenmesi gereken yöntem bu mudur yoksa yanlış mı yaptım ama sektörde olmadığım için kendi aklımca çözümler ürettim.

    Yani kısaca istediğim paketlerde "çiğ" veri görünmemesi, eğer TCP zaten bunu sağlıyorsa ben hiç XML'le yok şifrelemeyle falan uğraşmıyacağım, zaten 4-5 tane Entity var sistemde hepsinin de Serialize'ını da Deserialize'ını da kendim yazdım.

    Cevabınızı bekliyorum, önceki cevabınız için teşekkür ederim,
    İyi sabahlar.




  • quote:

    Orijinalden alıntı: Buzz Lightyear

    Ben kendi yazdığım kendime has TCP protokollerinde mümkün olabilecek herşeyi şifreliyorum.

    O kadar ki; bunlara "Request Code" diye tabir ettiğin kodlar ve mesajın/pakedin toplam byte olarak uzunluğu ve paket numarası da dahil. Hatta ve hatta şifrenin içerisine aynı zamanda mesajın yolda bozulup bozulmadığını test edebileyim diye mesajın SHA256 hashini de kattıktan sonra bir de üstüne üstlük mesaj ziplendiğinde daha da kısalmışsa zipli halini yolluyorum. Elbette tüm bu hadisenin çalışabilmesi için her mesajın önceden belirlenmiş/icat edilmiş sabit uzunluğa sahip bir "protokol başlığı"/header" gibi bir içeriğe sahip olması gerekiyor. Ekstra string verileri yine belirlenmiş bir şekilde bu başlığın arkasına eklenerek karşı tarafa yollanabilinir.

    Dolayısıyla Admin ve password de herhangi bir tarafa giden ister nümerik ister string bir bilgi/data olacağı için şifrelenmemesi için herhangi bir sebep göremiyorum.

    TCP programlama çok keyiflidir. Başarılar diliyorum.

    İlk cevabınızı daha sonra gördüm;
    Bir önceki mesajımda da söylediğim gibi, mesajı şekillendirme konusunda henüz birşey yapmadım ama "teori"sini öğrendik o işin. Verim çok ufak olduğu ve sunucunun çok ufak trafiğe sahip bir sunucu olduğunu düşünürsem sıkıştırmaya muhtemelen ihtiyacım olmayacak. Boyutla ilgili aklıma şöyle bir yöntem geliyor:
    - İlk 4 byte mesaj boyutu belirtmek üzere ayrılabilir.

    Şifreleme ile ilgili:
    Benim sorum aslında biraz şöyle; bu admin veya password (veya şifrelenecek x verisi) kendi başına şifrelenip örneğin;
    <requestPackage>SOMEENCRYPTEDDATA</requestPackage>
    Yoksa paketi komple mi şifrelemeli;
    [TOTAL][MESSAGE][LENGTH][BYTES][ENCRYPTEDPACKAGEBYTES]




    • Yapay Zeka’dan İlgili Konular
    Ubuntu Server TeamSpeak3 Server Kurulumu
    8 yıl önce açıldı
    IPTV Server
    2 ay önce açıldı
    OPENWRT client modda ip almıyor
    3 yıl önce açıldı
    Daha Fazla Göster
  • welrocken W kullanıcısına yanıt
    Ne kadar çok şifrelenebilinirse o kadar iyi.

    Sadece sana has olan, icat ettiğin, yarattığın iletişim protokolü içersinde mesajın byte olarak uzunluğu bile şifrelenmiş şekilde bulunabilir. Ama bunun olabilmesi için gereken şart uydurduğun, icat ettiğin protokolün muhakkak sabit bir uzunluğa sahip bir "header"ının olması lazım... Ötesi tamamen senin yaratıcılığına, ihtiyaç ve isteklerine bağlı.


    -------------------------------------------------------------------------------------------------------------------------------------------------------
    Bu arada şuna dikkat çekerim: (Bundan sonra bahsedeceklerim senin soruna ve ihtiyaçlarına çok alakasız ve zaten senin bildiğin hususlar olabilir, konuyu uzattıysam affola)

    Ham TCP protokolü veriyi şifrelemez. Hattı dinleyen kişi eğer mesajlar şifrelenmemişse dediğin gibi protokolü çözebilir, mesajları ve içeriklerini anlayabilir, değiştirebilir, kötüye kullanabilir. Zaten tabiyatıyle ham TCP protokolü teorik olarak internet üzerinde bulunan herhangi bir makineyle iletişime geçmeye muktedir olduğu için neyi neye göre şifreleyecek o da belirsiz. Dolayısıyla şifreleme işi senin omuzlarında.

    "Ham TCP" protokolüyle yollanan datalarda TCPnin kullanıcıya garantilediği tek şey yollanan byte'ların aynı sırada karşı tarafa ulaşması. Hoş o konuda bile bazen paketler birsürü internet noktasından geçerken yolda çok ufak bir olasılıkla arıza çıkabiliyor, sırası karışabiliyor. Dolayısıyla ben paketlerimin içersine kendi paket numaralarını da ekliyorum.

    Yani demek istediğim biz karşı tarafa "ABCDEFGH" diye bir byte dizisini tek seferde yollasak da karşı tarafa tek seferde "ABCDEFG" diye ulaşma garantisi yok. Mesela ilk etapta "ABCD" byte dizisi geldikten sonra geride kalan "EFG" dizisi mesela bir 1 saniye sonra gelebilir. Veya tam tersine biz birer saniye aralıkla "ABCD" ve "EFG" dizilerini fasılalı şekilde yollasak karşı taraf bunu tek ve birleşmiş bir dizi olan "ABCDEFG" şeklinde de alabilir. Takdir edersin ki bu davranış şekline her durumda hakim olabilecek ancak çok da kompleks olması gerekmeyen bir algoritma yazmak gerekecektir.

    Bu arada TCP'nin en "uyuz" yönlerinden biri bağlantı koptuğunda 2 taraf da bunu bilemeyebiliyor. Bu duruma da hazırlıklı olabilmek açısından dolayısıyla mesela client-server arası iletişimde eğer 1 dk boyunca herhangi bir veri gelişi olmamışsa kendine has bir PING protokolü de yazman gerekecek "ALOO ordamısn cevap veer" manasında. Mesela PING attıktan sonra 10 saniye içersinde gene senin icat ettiğin PONG cevabı yani "Burdayım abi buyur" cevabı gelmemişse o bağlantıyı kesersin mesela...

    Yine aynı şekilde bu konuyla ilgili olarak herhangi bir kullanıcıyı ONLINE zannedip aynı kullanıcıdan çok şaşırtıcı bir şekilde tekrar servera bağlanma ve online olma isteği/request alabilirsin. Ki çok doğal dediğim gibi TCPnin en uyuz yönlerinden biri bazen bağlantının koptuğunu bilemeyebiliyorsun. Bu durumda da Client bağlantının kesildiği anlamış ama server hala bağlantı var zannediyor ve bu da hiç de abuk bir durum değil benim Server-Client uygulamalarımda sıklıkla başıma gelen bir durumdur, dolayısıyla buna da hazırlıklı olmak lazım.

    Dolayısıyla kullandığın TCP kütüphanesi/kodları bu anlattığım hadiselere ne kadar destek veriyor ilk etapta onu bir araştırmak lazım. En sağlıklısı sokete ham olarak veriyi senin yazman ve okuman ve başkasının kütüphanelerine olan bağımlılığını mümkün mertebe azaltman... ama tabii onun da uğraşısı fazla olacaktır fakat getiri olarak en azından soket programlamayı tam manasıyla öğreneceksin.

    Bir ipucu vereyim ham TCP programlama konusunda özellikle server mimarisi için en efektif yöntem tek bir thread'den "Asenkron" yani "Non-Blocking Socket" tipi iletişim kurmak. Bunun da ötesinde "Overlapped Input Output" hadisesi var ki ben de oralara tam gelemedim. Bu işi bilenlerin yazdıklarına göre "Overlapped IO" yöntemiyle tek bir server ile ~10000 küsür client işlemi rahatlıkla yapılabiliniyormuş.

    Fakat bu soket, TCP iletişim vesaire konularıyla ilgilenmek fevkalade birşey yahu, ben takdir ettim gerçekten, valla helal olsun.




  • quote:

    Orijinalden alıntı: Buzz Lightyear

    Ne kadar çok şifrelenebilinirse o kadar iyi.

    Sadece sana has olan, icat ettiğin, yarattığın iletişim protokolü içersinde mesajın byte olarak uzunluğu bile şifrelenmiş şekilde bulunabilir. Ama bunun olabilmesi için gereken şart uydurduğun, icat ettiğin protokolün muhakkak sabit bir uzunluğa sahip bir "header"ının olması lazım... Ötesi tamamen senin yaratıcılığına, ihtiyaç ve isteklerine bağlı.


    -------------------------------------------------------------------------------------------------------------------------------------------------------
    Bu arada şuna dikkat çekerim: (Bundan sonra bahsedeceklerim senin soruna ve ihtiyaçlarına çok alakasız ve zaten senin bildiğin hususlar olabilir, konuyu uzattıysam affola)

    Ham TCP protokolü veriyi şifrelemez. Hattı dinleyen kişi eğer mesajlar şifrelenmemişse dediğin gibi protokolü çözebilir, mesajları ve içeriklerini anlayabilir, değiştirebilir, kötüye kullanabilir. Zaten tabiyatıyle ham TCP protokolü teorik olarak internet üzerinde bulunan herhangi bir makineyle iletişime geçmeye muktedir olduğu için neyi neye göre şifreleyecek o da belirsiz. Dolayısıyla şifreleme işi senin omuzlarında.

    "Ham TCP" protokolüyle yollanan datalarda TCPnin kullanıcıya garantilediği tek şey yollanan byte'ların aynı sırada karşı tarafa ulaşması. Hoş o konuda bile bazen paketler birsürü internet noktasından geçerken yolda çok ufak bir olasılıkla arıza çıkabiliyor, sırası karışabiliyor. Dolayısıyla ben paketlerimin içersine kendi paket numaralarını da ekliyorum.

    Yani demek istediğim biz karşı tarafa "ABCDEFGH" diye bir byte dizisini tek seferde yollasak da karşı tarafa tek seferde "ABCDEFG" diye ulaşma garantisi yok. Mesela ilk etapta "ABCD" byte dizisi geldikten sonra geride kalan "EFG" dizisi mesela bir 1 saniye sonra gelebilir. Veya tam tersine biz birer saniye aralıkla "ABCD" ve "EFG" dizilerini fasılalı şekilde yollasak karşı taraf bunu tek ve birleşmiş bir dizi olan "ABCDEFG" şeklinde de alabilir. Takdir edersin ki bu davranış şekline her durumda hakim olabilecek ancak çok da kompleks olması gerekmeyen bir algoritma yazmak gerekecektir.

    Bu arada TCP'nin en "uyuz" yönlerinden biri bağlantı koptuğunda 2 taraf da bunu bilemeyebiliyor. Bu duruma da hazırlıklı olabilmek açısından dolayısıyla mesela client-server arası iletişimde eğer 1 dk boyunca herhangi bir veri gelişi olmamışsa kendine has bir PING protokolü de yazman gerekecek "ALOO ordamısn cevap veer" manasında. Mesela PING attıktan sonra 10 saniye içersinde gene senin icat ettiğin PONG cevabı yani "Burdayım abi buyur" cevabı gelmemişse o bağlantıyı kesersin mesela...

    Yine aynı şekilde bu konuyla ilgili olarak herhangi bir kullanıcıyı ONLINE zannedip aynı kullanıcıdan çok şaşırtıcı bir şekilde tekrar servera bağlanma ve online olma isteği/request alabilirsin. Ki çok doğal dediğim gibi TCPnin en uyuz yönlerinden biri bazen bağlantının koptuğunu bilemeyebiliyorsun. Bu durumda da Client bağlantının kesildiği anlamış ama server hala bağlantı var zannediyor ve bu da hiç de abuk bir durum değil benim Server-Client uygulamalarımda sıklıkla başıma gelen bir durumdur, dolayısıyla buna da hazırlıklı olmak lazım.

    Dolayısıyla kullandığın TCP kütüphanesi/kodları bu anlattığım hadiselere ne kadar destek veriyor ilk etapta onu bir araştırmak lazım. En sağlıklısı sokete ham olarak veriyi senin yazman ve okuman ve başkasının kütüphanelerine olan bağımlılığını mümkün mertebe azaltman... ama tabii onun da uğraşısı fazla olacaktır fakat getiri olarak en azından soket programlamayı tam manasıyla öğreneceksin.

    Bir ipucu vereyim ham TCP programlama konusunda özellikle server mimarisi için en efektif yöntem tek bir thread'den "Asenkron" yani "Non-Blocking Socket" tipi iletişim kurmak. Bunun da ötesinde "Overlapped Input Output" hadisesi var ki ben de oralara tam gelemedim. Bu işi bilenlerin yazdıklarına göre "Overlapped IO" yöntemiyle tek bir server ile ~10000 küsür client işlemi rahatlıkla yapılabiliniyormuş.

    Fakat bu soket, TCP iletişim vesaire konularıyla ilgilenmek fevkalade birşey yahu, ben takdir ettim gerçekten, valla helal olsun.

    Selamlar
    Vesselam iyi bir programcıyım diyebilmek için aşağıda ki low level bilgilerin çok iyi bilinmesi gerektiğini düşünüyorum.
    1.OS seviyesinde kodların nasıl yorumlanıp değişkenlerin memoryde nasıl tutulduğuna kadar
    2.Network kısmı ve Socket Programlama vs.
    Bu konuyu görüp birazcık okuyunca bana da baya zevkli geldi. Aslında kendimi hep Application katmanı programcısı olarak gördüm bu sebepten böyle konular ilgimi çekiyor.
    Önümüze konulan ekmeği yiyoruz sadece bu sebepten sizi tebrik ederim.
    Yorumları keyifle okudum teşekkürler.




  • quote:

    Orijinalden alıntı: Buzz Lightyear

    Ne kadar çok şifrelenebilinirse o kadar iyi.

    Sadece sana has olan, icat ettiğin, yarattığın iletişim protokolü içersinde mesajın byte olarak uzunluğu bile şifrelenmiş şekilde bulunabilir. Ama bunun olabilmesi için gereken şart uydurduğun, icat ettiğin protokolün muhakkak sabit bir uzunluğa sahip bir "header"ının olması lazım... Ötesi tamamen senin yaratıcılığına, ihtiyaç ve isteklerine bağlı.


    -------------------------------------------------------------------------------------------------------------------------------------------------------
    Bu arada şuna dikkat çekerim: (Bundan sonra bahsedeceklerim senin soruna ve ihtiyaçlarına çok alakasız ve zaten senin bildiğin hususlar olabilir, konuyu uzattıysam affola)

    Ham TCP protokolü veriyi şifrelemez. Hattı dinleyen kişi eğer mesajlar şifrelenmemişse dediğin gibi protokolü çözebilir, mesajları ve içeriklerini anlayabilir, değiştirebilir, kötüye kullanabilir. Zaten tabiyatıyle ham TCP protokolü teorik olarak internet üzerinde bulunan herhangi bir makineyle iletişime geçmeye muktedir olduğu için neyi neye göre şifreleyecek o da belirsiz. Dolayısıyla şifreleme işi senin omuzlarında.

    "Ham TCP" protokolüyle yollanan datalarda TCPnin kullanıcıya garantilediği tek şey yollanan byte'ların aynı sırada karşı tarafa ulaşması. Hoş o konuda bile bazen paketler birsürü internet noktasından geçerken yolda çok ufak bir olasılıkla arıza çıkabiliyor, sırası karışabiliyor. Dolayısıyla ben paketlerimin içersine kendi paket numaralarını da ekliyorum.

    Yani demek istediğim biz karşı tarafa "ABCDEFGH" diye bir byte dizisini tek seferde yollasak da karşı tarafa tek seferde "ABCDEFG" diye ulaşma garantisi yok. Mesela ilk etapta "ABCD" byte dizisi geldikten sonra geride kalan "EFG" dizisi mesela bir 1 saniye sonra gelebilir. Veya tam tersine biz birer saniye aralıkla "ABCD" ve "EFG" dizilerini fasılalı şekilde yollasak karşı taraf bunu tek ve birleşmiş bir dizi olan "ABCDEFG" şeklinde de alabilir. Takdir edersin ki bu davranış şekline her durumda hakim olabilecek ancak çok da kompleks olması gerekmeyen bir algoritma yazmak gerekecektir.

    Bu arada TCP'nin en "uyuz" yönlerinden biri bağlantı koptuğunda 2 taraf da bunu bilemeyebiliyor. Bu duruma da hazırlıklı olabilmek açısından dolayısıyla mesela client-server arası iletişimde eğer 1 dk boyunca herhangi bir veri gelişi olmamışsa kendine has bir PING protokolü de yazman gerekecek "ALOO ordamısn cevap veer" manasında. Mesela PING attıktan sonra 10 saniye içersinde gene senin icat ettiğin PONG cevabı yani "Burdayım abi buyur" cevabı gelmemişse o bağlantıyı kesersin mesela...

    Yine aynı şekilde bu konuyla ilgili olarak herhangi bir kullanıcıyı ONLINE zannedip aynı kullanıcıdan çok şaşırtıcı bir şekilde tekrar servera bağlanma ve online olma isteği/request alabilirsin. Ki çok doğal dediğim gibi TCPnin en uyuz yönlerinden biri bazen bağlantının koptuğunu bilemeyebiliyorsun. Bu durumda da Client bağlantının kesildiği anlamış ama server hala bağlantı var zannediyor ve bu da hiç de abuk bir durum değil benim Server-Client uygulamalarımda sıklıkla başıma gelen bir durumdur, dolayısıyla buna da hazırlıklı olmak lazım.

    Dolayısıyla kullandığın TCP kütüphanesi/kodları bu anlattığım hadiselere ne kadar destek veriyor ilk etapta onu bir araştırmak lazım. En sağlıklısı sokete ham olarak veriyi senin yazman ve okuman ve başkasının kütüphanelerine olan bağımlılığını mümkün mertebe azaltman... ama tabii onun da uğraşısı fazla olacaktır fakat getiri olarak en azından soket programlamayı tam manasıyla öğreneceksin.

    Bir ipucu vereyim ham TCP programlama konusunda özellikle server mimarisi için en efektif yöntem tek bir thread'den "Asenkron" yani "Non-Blocking Socket" tipi iletişim kurmak. Bunun da ötesinde "Overlapped Input Output" hadisesi var ki ben de oralara tam gelemedim. Bu işi bilenlerin yazdıklarına göre "Overlapped IO" yöntemiyle tek bir server ile ~10000 küsür client işlemi rahatlıkla yapılabiliniyormuş.

    Fakat bu soket, TCP iletişim vesaire konularıyla ilgilenmek fevkalade birşey yahu, ben takdir ettim gerçekten, valla helal olsun.

    Bilgilendirici cevabınız için teşekkür ederim, böyle forumdaşların olması çok sevindirici :)

    Amatör olarak 4-5 yıldır C# ile kod yazıyorum & yazmaya çalışıyorum, çocukluk hevesi" (diye düşünüyorum) ilk 3-4 yılımı oyun yazmaya çalışarak geçirdim. XNA falan öğrendim Unity3D falan öğreniyim derken baktım ki tek başına oyun falan yazılmaz (benim ilgimi çeken tipte oyunlar en azından).

    Daha sonra üniversitede gördüğümüz derslerin, staj yaptığım yerdeki projelerin ve üniversiteden arkadaşımla giriştiğim ufak tefek projelerin vasıtasıyla, bu işe ilk giriştiğimde nefret ettiğim iletişime bir anda ilgi duymaya başladım.

    Server tarafını yazarken karşılaşılan zorluklar olsun, programcının yazdığı kodun şekillenişi olsun, protokoller, güvenlik aşamaları olsun cidden çok keyifli bir iş gibi geliyor. Umuyorum devamı gelir.

    Tekrar teşekkürler,
    İyi akşamlar.




    • 
Sayfa: 1

Benzer içerikler

- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.
Hizmet kalitesi için çerezleri kullanabiliriz, DH'yi kullanırken depoladığımız çerezlerle ilgili veri politikamıza gözatın.
Kabul Ediyorum