Názory k článku FSP protokol - Internetová Legenda (4)

Tak sme sa dockali nejakeho toho masa. Hura.
Inak, az doteraz som neveril, ze nieco ako FSP naozaj existuje, bral som to ako kvalitne vymysleny clanok... ale.. prave som vygooglil fspd server na stiahnutie z 5.1.2005, co ma uplne dostalo. NECH ZIJE FSP!!!

Nejlepsi byly ty clanky Radima Kolare o Cyberspace v Netmagu. Nechtel by root neco takoveho taky vydavat? :-)

Nejak jsem nezaznamenal nic z oblasti SW designu, co bych mohl obdivovat ;-) Jedine pozoruhodne je (z historickeho hlediska) pouziti UDP window-less protokolu jako primitivni QoS techniky, ktera znevyhodnuje FSP oproti TCP spojenim :-)

Presne tak. O FSP jsem slysel poprve skoro zaroven s FTP, ale nikdy jsem neprisel na to, proc bych mel FSP pouzivat. Z implementace je jasne, ze se pouzivaji (emuluji) v podstate tytez algoritmy jako v TCP, mozna jen s jinymi parametry.

Historicka poznamka: ono i to prihlasovani a zadavani e-mailove adresy do anonymniho FTP k necemu bylo. V dobach, kdy byly FTP servery s limitem 5-10 uzivatelu, se mi stalo, ze jsem dostal mailem informace od administratora FTP serveru, ze ktereho jsem predtim neuspesne stahoval nejaky soubor (tusim ze meli spatne nastavena pristupova prava) - administrator psal, ze ten problem opravil.

-Yenya

Mne spis pripada primitivni rvat qos do ip hlavicek a doufat, ze se tim budou routery ridit.

Stejne primitivni, jak tam rvat adresu prijemce a doufat, ze se ji budou routery ridit? ;-)

Ne, je pravda, ze puvodni IP QoS se moc neujal. Ale IMHO spis proto, ze zdroje nebyly poctive v oznacovani packetu.

UDP nijak nebrání, aby ty packety podvrhnul někdo jiný (že není spojení a že to nemá TCP sequence number)

Co brání tomuto scénáři:
FSP klient: Chci 1024 bajtů z offsetu 2048 ze souboru /pub/fsp-2.8.1b22.tar.bz2
Hacker: Tady máš ty data.
...

človek si mysli, že stahuje skvělý nový FSP server a místo toho si stáhne skvělý nový backdoor...
(dobrá, můžou k tomu přidat .bz2.sign, ale určite se někde najde lama, která si to neověří + kdo si to ověří musí stahovat znova...)

Nebo jednoduchý DoS: s podvrženou IP adresou posílám na server požadavky bez klíče nebo s neplatným klíčem v intervalu řekněme 50s. Z dané IP adresy si nikdo nic nestáhne...

BTW, neměl být ten odstavec o klíčování ještě před odstavcem "Ty sis zapomněl klíče?" ?

V době, o které je tu řeč, nevznikalo moc protokolů, při jejichž návrhu by byla bezpečnost nějak výrazněji brána v úvahu...

1. Pokud se hacker nacpe mezi klienta a server, tak sejme TCP bez problemu taky. Viz hracky v Debianu..

2. Posilani nahodnyho packetu po 50 sekundach nezabere, zabralo by ovsem posilani packetu porad se stejnym klicem. To mne nenapadlo a nastesti to lze oneline fixem opravit. Takze dik.

No, když tak ten článek čtu... Spousta keců, jinak to, co si člověk může přečíst v manuálu.

Tak pár věcí se mi doopravdy nelíbí. Jak se prosímvás řeší to, čemu se u KISSu říkalo ,,Snowball efekt''? Tam tento problém způsoboval přímo modem, což nakonec vedlo Toma k implementaci frame killeru, ale zde může snowball nastat také, ikdyž tu neexistuje institut potvrzování.

Příklad:
Klient odešle serveru požadavek na část souboru. Tento požadavek nabere v síti nějaký divný směr, takže dorazí k cíli až v momentě, kdy díky timeoutu stačí klient poslat řekněme 19 dalších požadavků. Server by tedy měl poslat zpět 20x totéž. Ovšem s největší pravděpodobností dorazí requesty naráz, neb linky se různě sdílí a přiděluje se na nich čas, nebývá to takový ten chaos znamý z malých sítí. Když tedy server pošle zpět 20x totéž, ucpe tím linku, přičemž jakmile první packet dorazí klientovi, pošle další request. Tomu bude cesta k serveru trvat ještě déle, než před tím, neb linka bude ucpaná těmi 19 zbytečnými packety, přičemž se těch requestů podaří poslat o trochu víc, než před tím. Tenhle stav se bude už jen zhoršovat, až to ve finále dopadne tak, že síť bude zahlcena packety aniž by se přenášela nějaká užitečná data.

Řešení založené na měření času odezvy a dle toho úpravy timeoutovacího časovače zase povede k tomu, že jedna menší porucha na lince na solidně dlouhou dobu ucpe přenos, čili nastane stav, který autor vytkl protokolu TCP. Čili kde je ta výhoda?

Nechci se zastávat ftp, neb to je zrůdnej protokol. Ale celkem chápu člověka, kterej o FSP prohlásil, že je to zlej program.

ty kokšo, tak si přečti manuál a dej pokoj.
třeba se najde někdo kdo se poučí, mě to sice
nijak extra nezajímá, ale přečtu si to rád.

nefunguji neb server nepreposle data rychleji nez 1x za 3 sec. Dostane sice hafo pozadavku na resend, ale posle jeden a zbytek zahodi. Pokud je na siti bezny ping time > 3s, tak lze server nastavit treba na 10 sekund.

Asi bych mel napsat jeste jeden vzdelavaci dil pred silvestrovskym. Nejdriv prace, potom zabava ;( Vlastne moment. Nejdriv duchovni pokrok a zabava neni nutna -- je v tom jiz zahrnuta.

sice to nesouvisi s clankem, ale myslim ze mate bug v RS (nebo me nekde zradila proxy)

http://widlaksoft.cjb.com/store/dira1.png
// toto je zobrazeno pod clankem

http://widlaksoft.cjb.com/store/dira2.png
// toto je pod komentari

ja mam obi2 rovnake, takze asi to nebude bug...

Jak tak koukam do /etc/services, tak příští článek se bude jmenovat "Tajemstvi protocolu echo" a vyjde v 10 pokračováních na Novém ROOTu. Na bílem pozadi a bez jedineho tagu TABLE. To bude bomba !

Jsou lepsi sluzby -- chargen, discard, time :) Nebere root prispevky v .PNG formatu?

copak chargen a discard, ale tcpmux to je teprv maso, o tom by se mel napsat nejaky serial.

nejsem v tomto moc zbehli, ale pochopil jsem spravne ze FSP je protokol z skupiny TCP a UDP? takze ho musi podporovat OS nebo je FSP (jako HTTP na TCP/IP) postavene nad UDP/IP ??
btw. pokud je prvni moznost spravne,i kdyz je tohle ciste lin server,jaky OS FSP a podporuje?

Nejsem v tom taky zbehly, ale z clanku (nebo z nejakeho predchoziho dilu) je zrejme, ze druha moznost je spravne. Plyne z toho vyhoda, ze muzes mit na jednom stroji spustenych nekolik serveru, kazdy na jinem portu, i kdyz to se asi tenkrat nedelalo.