Re: Ang. juks

[Tore Skaug <toresk@pvv.ntnu.no>]

On Tue, 24 Nov 1998, Sigmund Motzfeldt \y wrote:

> > Det vil kreve mye plass, men det er grunner til at jeg synes det i det
> > minste boer vaere mulig.
> 
> Helt enig. Det boer vaere mulig. Det jeg sa var vel bare at jeg helst ikke
> ville kreve det. (klienten velger selv sin lokale cache stoerrelse)

Saa lenge vi skriver med tanke paa en cache-mekanisme, er det jo egentlig
ett fett, mekanismen for overfoering vil vaere det samme. Det vil vel fort
vise seg hvor mye data det blir snakk om for klienten sin del.

Ett aspekt her er gruppe-dynamikk, det blir litt pes for en gruppe dersom
ett av medlemmene til stadighet henger pga. liten cache og daarlig
baandbredde.  Derfor burde en gjerne kunne sette noen minimumskrav til hva
en forventer av cache-kapasitet hos en klient slik at det ikke oedelegger
for andre at noen spiller paa full disk paa dj.

> Ellers gir du jo som meg vekk objektenes innhold nesten helt gratis. Du
> gir jo innholdsnoekkelen til brukeren. Det er jo likevel et poeng at en
> ikke skal kunne kikke paa alt en faar ned paa disken foerste gang en
> logger seg paa. (se kommentarer under)

Dette er forsaavidt noe som er en del av en debatt som er kommet i noen
senere mails her, men mitt syn paa verden er at klientens kunnskap om
objektene er svaert liten. Den begrenser seg til noe slikt som informasjon
objektet trenger for aa tegne seg selv, rutiner for aa gjoere grafiske
operasjoner (doer som aapner seg ol.) med objektet og som tar visse
parametre, samt kunnskap om hva en vet at en kan forsoeke aa gjoere med
objektet. Jeg kommer til aa skrive et eller annet som forhaapentligvis har
noe for seg senere i dag ang. hva jeg tror kan fungere for dette.

> Det blir vanskelig aa sammenlikne baser, men det blir ikke vanskelig for
> en newbie aa kopiere hele basen til en erfaren spiller og utforske denne
> offline. Det var i bunn og grunn dette problemet jeg mente vi ikke hadde
> mulighet til aa gjoere noe med. Om du har en loesning paa det saa er det
> definitivt spennende.

Dette kaller jeg en utfordring snarere enn et problem :-)  Fra spoek til
Halvor, jeg tror ikke det kan la seg gjoere saa lenge klienten skal
utfoere kode av noe slag, enten det er lisp eller hva som helst, aa
beskytte klienten fra denne informasjonen. En OpenGL-sak vil maatte se
textures naar de skal vises, saa de kan heller ikke beskyttes.

Jeg tror ikke dette er saa ille, men jeg skal som sagt tenke litt mer paa
dette utover dagen.

> Naar det gjelder problemene med at en RL person har flere personligheter i
> spillet, saa kan dette loeses forholdsvis enkelt.
> Vanligvis vil en jo kreve at kun en av disse personlighetene er logget paa
> av gangen, samt at det ikke er noen kontakt mellom dem. I saa fall kan en
> operere med en slags konto for hver RL person der han registrerer alle
> sine ulike personligheter. Dette er praktisk ut fra et oenske om aa
> kontrollere at folk foelger reglene i spillet og kan samtidig benyttes
> kodemessig for aa gi denne kontoen ett sett noekler som deles mellom alle
> de registrerte personlighetene. Et slikt kontosystem vil ikke inneholde
> noen personinformasjon saa det skulle ikke vaere noe problem lovmessig
> sett. Det eneste vi vil lagre om eieren av kontoen er jo passordet han
> bruker. Vi kan jo ogsaa haape paa at spillerne klarer aa hoste opp litt
> bedre passord om de ikke maa ha ett for hver personlighet.
> 
> Dersom flere RL personer skal dele samme disk har vi et problem. Det vi
> kan gjoere er jo aa si at de neppe vil dele disk om de ikke sitter
> forholdsvis naert hverandre. I saa fall saa deler de jo all annen info, 
> saa vi kan la dem soeke spillets administratorer om aa faa dele
> samme noekkelsett.

Dette er en god ide, og loeser problemet greitt.

> For aa summere opp : jeg synes systemet ditt var bra, og synes og godt vi
> kan kryptere objektinnhold selv om det ikke helt adresserer problemet med
> deling av data. Kryptering vil jo gjerne ogsaa kombineres med kompresjon
> som ikke er aa forakte.

Og som du er inne paa i en annen mail, det er ikke vanskelig aa starte med
en versjon uten kryptering/id-obfuskering dersom det er tilstrekkelige
'hooks' for aa legge dette inn senere.

Kryptering gjoer det nok ikke lettere aa faa til kompresjon, snarere er
det slik at krypterte data er umulig aa komprimere ettersom de er
fullstendig random. Men med 'hooks' er det lett aa gjoere ingenting,
kompresjon eller kompresjon-kryptering uten at mye maa endres.



- Tore