«« ( Date ) »» // «« ( Thread ) »» // mips-nastava - 2003

Re: tcp/ip

by Sasa Rudan
sreda, 05. mart 2003 - 22:03.

> TCP/IP stek za host ili za ruter? U kakvoj mrezi (Ethernet, Token Ring,
> ...)?

Nije ni bitno da li je host ili gateway(IP ruter) jer je mala razlika u
stekovima, a algoritmi rasporedjivanja paketa nisu toliko znacajni na ovom
nivou niti projektu. Radio sam neki gateway (DOS sa PktDRV
drajverima)(koji je unisten na disku i ostale su samo neke backup Ethernet
klase i malo dokumentacije) sa multiprocesiranjem IP saobracaja, ali i tu
mi se razlikovao samo Physical (uglavnom Ethernet) stek. Za Ethernet i
Token Ring se cak ni fizicki stek ne razlikuje vec se uzmu drugi drajveri
koji odgovaraju datoj mreznoj kartici. Vidjao sam cak i mrezne drajvere
koji su emulirali mreznu karticu preko SLIP protokola (nakacenog naravno
na serijski port) pa je i tada sve islo OK, skroz transparentno.

> Pa onda i ne vidim sta tu ima da se radi kada za sve za sta postoji C
> kompajler postoji i gomila open TCP/IP stekova. Ostaje jedino taj deo sa
> premestanjem u hardver, ali, meni se cini da se tu bas i ne dobija
> nesto spektakularno (barem kod hostova, kod rutera je prica sasvim
> drugacija) o da su C kompajler + procesor opste namene sasvim
> dovoljni.

IP ruteri sprezu racunare u lokalnoj mrezi sa spoljnom mrezom i ne vidim
razlog zasto bi neki gateway koji ima recimo samo 2 mrezne kartice kako je
cesto i slucaj imao vecu potrebu sa hardverskim rjesenjem od nekog
IP-klijenta koji ima potrebu za ogromnim propusnim opsegom koji bi se
mogao pojaviti kod nekih hardverski specificnih uredjaja. Pa i sami hubovi
i switchevi prenose nista manje paketa koliko i gateway. Dakle jednako su
optereceni i Ethernet ruteri i IP ruteri, tako da "ozicavanje" IP rutera
je itekako aktuelno. Druga je prica oko teskoce realizacije svega toga i
naknadne modifikacije i monitoringa svega toga, ali zato je jos i veci
izazov, a sa druge strane svi ti problemi su manje kriticni za ovaj
projekat.

> pa ok. Onda mogu da smatram da ces ti to da ubudzis u 8x51.(imaj na umu
> da ovo nije 486 ili bolji). Imas maksimalno 32K ROM-a i 32K RAM-a. HTTP
> treba da bi bio lak za upravljanje (naravno ispod njega mora da postoji
> i TCP/IP). treba da podrzava samo osnovne stvari, moze da se maksimalno
> suzi za specificnu namenu.

naravno, nikakva (de)fragmentacija IP paketa, ...

> Takodje otaje problem povezivanja na Eternet kontroler.

Gledao sam PktDRV drajver source code za neku 3COM karticu i da se lako
svariti, mislim da nebi trebalo biti nikakva frka, a nasao sam negde sajt
nekih entuzijasta koji prodaju gotove module sa, mislim RTL8029, Ethernet
cipom pa moze to da se koristi.

> Btw, jel' se misli na 10BaseT ili 100BaseT Ethernet?
Sta je uopste frka za to?

> P.S. Ne vidim zasto protokol tako visokog nivoa kao sto je HTTP. Nekako
> mi se cini da je veliki overhead praviti citav web server za nesto tako
>jednostavno kao sto je upravljanje
> procesima (jeste da ce to pojednostaviti/olaksati > kasniji razvoj, ali po
> koju cenu). Zasto ne TCP/IP?

Kada se vec odradi TCP automat i ostalo, HTTP je OK. Ja sam pisao proxy
servere u Perlu sa samo par desetina redova, a web server je jos
manji. Overhead samog HTTP protokola nije ni priblizno kritican po tom
pitanju, jer nama ne trebaju takve egzotike kao sto su PRAGMA,
PROXY-CONNECTION, niti negotiation, ... vec ono sto je nuzno, a to nuzno
nam bas olaksava rad i omogucava fantasticnu kontrolu, npr. virtualizaciju
uredjaja preko njihovih URL-ova kao da ih na UNIXu mauntujemo na fajlove,
... Jedno smo za Veljka radili neki distribuirani sistem u Perlu koji je
komunicirao preko HTTP protokola (koji je blago modifikovan zbog pracenja
sesija) i bila je super stvar jer se cijeli sistem mogao testirati preko
standardnih brauzera i lako su se dibagirali svi nastali problemi, ali
overhead koji takav pristup daje je po meni kontradiktoran sa hardverskom
realizacijom svega ovoga. Po meni bolje rjesenje je UDP.

pozdrav
Sas Rudan
-------------------------------------------------------------------------------
Conntact me via e-mail mprinc@galeb.etf.bg.ac.yu=20
mprinc@aim.ac.yu
or home page: http://galeb.etf.bg.ac.yu/~mprinc
-------------------------------------------------------------------------------