IDOS a veci souvisejici

[Martin.Postulka at cerge.cuni.cz]

>> 	Je-li v cookie skutecne pointer, pak rozhodne nejde o

>Pozor, spatne jste cetl. Vyse jsme psal, ze je lepsi
>citliva data (pointer) neprenaset vubec. Proto NEJSOU
>ulozena v Cookies. Psal jsme to jiz mnohokrat. Proc tedy
>porad vytahujete domnenku, ze v Cookies je pointer?

Asi by bylo lepsi citovat cely odstavec pana Kasprsaka,
protoze to podstatne je v jeho zaveru. Velmi vas prosim,
prectete si ho jeste jednou s mym vykladem a pokuste se
na to odpovedet z tohoto pohledu.

pan Kasprsak:
>Je-li v cookie skutecne pointer, pak rozhodne nejde o
>"uzivatelem neovlivnitelny" prenos informace; tento pristup je pak
>nebezpecny, a IDOS spadne, pokud si necham dva dny otevrene okno,
>protoze pouzije neplatny pointer. Pokud je ale v cookie nejaky index do
>tabulky pointeru, jehoz platnost se po obdrzeni serverem testuje,
>pak stejna informace muze byt klidne v URL nebo v hidden polozce.
>Nehlede na to, ze touto informaci mohou stejne dobre byt parametry
>daneho spojeni.

Ja jsem to pochopil tak, ze dava do kontrastu dve eventuality.
Snad by podminovaci zpusob lip vyhovel tomu, ze prvni moznost
v IDOSu pouzita neni:
Kdyby byl byval v cookie skutecne pointer, pak by ...
Pokud je ale v cookie nejaky index ...jehoz platnost ...se testuje



Pokuste se prosim potvrdit, nebo vyvratit druhou cast Yenova odstavce!



>>Bylo by jich aspon tolik, co je nyni hitu do "cache",
>>vedene mechanismem sessions.

>Nyni to je temer tretina dotazu, kdy se vyuziji
>predpripravena
>data vyhledaneho spojeni (to co oznacujete jako hit do
>"cache").
>Analyzou LOGu vyhladavanych spojeni by se ukazalo
>(nyni jen odhaduji), ze kdyby se cachovalo podle Vami
>navrhovanych parametru spojeni, jednalo by se o zlomek
>procenta.
>Pomer je jasny: cca 30 % ku 0.x % ve prospech stavajiciho
>reseni.

Neni mi jasne, proc by mel byt takovy nepomer mezi temito
moznostmi.

Rekneme, ze nyni v jedne tretine pripadu uzivatel upresni
dotaz (nebo neco takoveho) cimz zada dalsi dotaz, kde puvodni
parametry dotazu meni takovym (definovatelnym) zpusobem, ze lze
pouzit nektera uz nalezena data.
(napriklad da dotaz na spojeni v jinou dobu, takze neni treba hledat
jinou trasu) Vy jiste budete vedet priklady jinych takovych zmen.

Tj. v jedne tretine pripadu nastanou podminky pro, rikejme tomu
svorne "hit do cache". :-)

Ve vasem provedeni je uzivatel identifikovan ASPSESSIONID,
nalezena odpovidajici datova oblast, ale stejne musite zkontrolovat
parametry dotazu, (jestli se nahodou uz nepta na neco uplne jineho)
jestli plati vyse popsane podminky. A pokud plati, "hit do cache",
pro dalsi data do databaze, vyhodnotit, zodpovedet.
Nebo je to jinak?

V modelu pana Kasprsaka je dotaz identifikovan svymi parametry,
takze kontrola, ci vyhodnoceni parametru je prvotni, ale pak se
dostanete do stejne (tedy uplne jinak postavene, ale v danem okamziku
stejne naplnene) cache, takze kdyz muzete delat "hit da cache" vy,
tehdy on taky.




>Analyzou LOGu vyhladavanych spojeni by se ukazalo
>(nyni jen odhaduji), ze kdyby se cachovalo podle Vami
>navrhovanych parametru spojeni, jednalo by se o zlomek
>procenta.

Tim myslite opakovani uplneho vektoru parametru, tj.
misto1, misto2, via, cas odjezdu nebo cas prijezdu?

Samozrejme idealni by bylo, kdyby datova oblast byla natolik
inteligentne strukturovana, ze by se dal dotaz indexovat nekolikrat
podle ruznych rozumnych podskupin parametru. Nejjednodussi priklad
je indexace jen podle trati (bez terminu).
(popravde receno mne momentalne nenapada jiny :-(  )

To ovsem eventuelne muzete mit opravnenou namitku, ze to pouzivane
knihovny neumoznuji. Bylo by to smutne, ale neda se to vyloucit.
Nicmene byl by to podnet pro upravu techto knihoven.

Martin Postulka