Transparentnejsi proxy cache?

[Lazo Igor]

> : - cache musi ustavit TCP spojeni s klientem
> :   ( asi se tedy bude vydavat za cilovy server )
>
> 	Ano, o to se postara napriklad router.
>
TCP spojeni neni bezestavove, takze router sem,
router tam, ustavit to musi cache. Cilovy server o nicem nevi.
TCP spojeni se ustavi teprve po vymene asi 3 datagramu.

> : - TCP spojeni obsahuje poradova a potvrzovaci
> :   cisla, ktera zacinaji nahodnym cislem a zvetsuji
> :   se primo umerne s poctem prenesenych bajtu
>
> 	Bezpochyby. Ale nema to co do cineni s vlastni proxy cache.
>
Toto musi zaridit transparentni proxy cache.
Mozna vam nerozumim.

> : - v pripade snahy o prehozeni existujiciho
> :   TCP spojeni na cilovy server by tudiz
> :   s pravdepodobnosti hranicici s jistotou onen
> :   server poslal jine iniciacni poradove cislo
> :   TCP spojeni
>
> 	Tady se neprehazuje zadne existujici spojeni. U transparentni proxy
> klient primo vytvari TCP spojeni s tim proxy (i kdyz o tom nevi).
>
Nerozumim vam. Klient si mysli, ze ustavil spojeni s cilovym serverem.
Transparentni proxy cache zjisti, ze spojeni, ktere odchytila je http
RELOAD az kdyz ho ustavi a chvili komunikuje. Takze kdyz neprehazovat,
tak jak ? Pristi spojeni musi taky odchytit, aby mohla analyzovat obsah.

> : - "srovnat krok" by bylo mozne jen prenesenim
> :   adekvatniho mnozstvi dat ( az 2na31 ) - takze
> :   takhle asi ne.
> [...]
> : Co na to znalci http, html, ASP apod. ?
>
> 	S vyse uvedenym tohle nema nic spolecneho. Tady jde o TCP.
>
No, prave.

> Pripominam, ze transparentni (z hlediska klienta) proxy uz mame
> zvladnutou.
> Jde jen o to, jestli by slo squid presvedcit, aby nepouzival bezne
> sockety,
> ale (napriklad) raw sockety, do kterych by posilal primo packety se
> zdrojovou
> adresou puvodniho tazatele (cili jde mi o proxy "transparentni" z hlediska
> WWW _serveru_).
>
To neresi stavovost TCP

S pozdravem

Igor Lazo