From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Sun 30 Mar 2003 - 15:46:45 EEST
Selamlar..
IETF'nin soylemeye calistigi sanirim TCP ile broadcast yapmaya calisin
degil. UDP gibi bir datagram ile TCP benzeri senkronizasyon saglayin
demek istiyor saniyorum. Aksi olsaydi TCP protokolunun yeniden yazilmasi
gerekirdi.=20
Bu nasil yapilir ? Bunu gormek icin RTP protokolunu incelemek yeterli
olur. RTP'de reliable bir baglanti saglar. Ama connection oriented
degildir. Halbuki TCP connection oriented calisir.
SYN Flood'u engellemek o kadar kolay degil. Ne yaparsaniz yapin kolay
degil. Gozden kacirdiginiz husus, sizin layer 5 icinde yapmaya
calistiginiz "bu dogru adresten geliyor mu ?" kontrolunu layer 3/4
uzerinde halletmek. Aslinda CPU yuku vs. icin degisen bir sey yok. Sizin
BSD veya kernel kodu icindeki kadar verimli bir kod yazamadiginizi
dusunebiliriz. Diger yandan sizin TCP icin IP SOCKET FILTER'i devreye
aliyor olmaniz ile netfilter'e bir kural eklemeniz arasinda fazla bir
fark yok.
SYN paketi gelince diyelim ki, spoof edildi. Atlayacak stack gene ACK
yollamaya..
Bu sorunu ilk yasayan siz degilsiniz. Bunun icin TCP ile bogusmaktansa,
Multicast TCP diye bilinen RMCCP, MTCP gibi protokolleri denemeniz veya
bir benzerini UDP uzerinde kendinizin saglamaniz daha uygun olacaktir.=20
Kisacasi standart TCP ile bu isin cozulmesi zor. Ama mesela, ne oldu,
production ortama gecirilebildimi bilmiyorum, TCP-SMO diye bir calisma
vardi. Burada master/slave socketler vs. ile TCP imis gibi davranan bir
tur datagram uygulamasi gelistiriliyordu.=20
TCP ile yaptiginizda bu TCP olmaktan cikacak. Orta vadede hic akliniza
gelmeyecek sonuclar yasanmaya baslanacak. Cunku TCP bu is icin
hazirlnamis bir sey degil. Su error correction vs. meseleleri zaten bir
hayli halledilmis durumda.=20
SAygi ve sevgiler..
On Sun, 30 Mar 2003 12:10:06 +0000
"yilmaz kemal y=FCce" <ykyuce@hotmail.com> wrote:
>=20
>=20
> Tekrar merhaba,
>=20
> =F6ncelikle ilginiz i=E7in =E7ok te=FEekk=FCr ederim. Asl=FDnda protokol=
=FCn
> detaylar=FDna girmem gerekiyormu=FE anlad=FD=F0=FDm kadar=FD ile. =C7oklu=
yay=FDn=FD IP
> Multicast katman=FD ile yapaca=F0=FDm yine. Burada yanl=FD=FE anla=FE=FDl=
ma olmas=FDn.
> Yani Datagram tipi(UDP) soketler kullan=FDyorum. Lakin mesele
> reliability kazand=FDrmak oldu=F0u i=E7in IP Multicast'a ve okudu=F0um
> yay=FDnlarda ve IETF'in ald=FD=F0=FD kararlara uygunluk sa=F0lamas=FD i=
=E7in
> mesaj/data retransmisyonunu TCP =FCzerinden halledilmesinin en
> ak=FDll=FDcas=FD oldu=F0una karar verdim. Zira IETF diyor ki "herhangi bir
> (Reliable)G=FCvenilir =C7oklu Yay=FDn Protokolu, TCP'nin congestion contr=
ol=20
> mekanizmasi ile uyumlu bir congestion controlune sahip olmalidir.".
> Elbette bu aslinda Internet uzerindeki veri transmisyonunun %95'nin
> TCP arac=FDl=FD=F0=FD ile sa=F0lanmas=FDndan ama bunun yan=FDnda yerel a=
=F0 i=E7in
> yap=FDlan b=FCy=FCk =E7apta deneyler TCP'nin UDP'den =E7o=F0u zaman daha =
h=FDzl=FD
> oldu=F0unu kan=FDtl=FDyor. Tekrar ediyorum "b=FCy=FCk =E7apta". E ben de =
bu
> fikirden hareketle IP Multicast'in guvenilirli=F0ini sa=F0layacak ve error
> recovery yapacak k=FDsm=FD TCP'nin =FCzerine y=FDkt=FDm ve protokolun
> =E7ekirde=F0ini olu=FEturan, baz=FDlar=FD taraf=FDndan master baz=FDlar=
=FD taraf=FDndan
> da sequencer diye adland=FDr=FDlan grup =FCyesine TCP soketi ile
> retransmisyon sunucusu kurmal=FDy=FDm diye d=FC=FE=FCnd=FCm. Bu grup =FCy=
esinin
> protokolun di=F0er baz=FD gerekleri i=E7in =F6nemli rol=FC var, bunlara g=
irmeye
> gerek g=F6rm=FCyorum. Merak eden olursa baz=FD dok=FCmanlar sa=F0lar=FDm.