[Gzz] hh gradu

[Tuomas Lukka]

4.3:

    SHA-1 2 cryptographic content hash [124] is used for creating...

"Creating"? it *is* the id...

    Additionally, SHA-1 [124] is used for verifying the integrity of Storm data 
blocks.

A different SHA-1? Sounds like that. The point is that id is
*directly* the verifier as well.

    Storm blocks have much in common with regular  les,

What exactly? They don't have names, and can't be changed. What's left?

    This mechanism creates a basis for

What mechanism? A very confusing paragraph so far, jumping around a lot.

Kuvaan 4.2 ei ole viittausta?
Kuvateksti 4.2 aivan riittämätön, luuletko lukijan tuosta tajuavan mitään?
Mikä on "stormOther"?

    Figure 4.3 illustrates simpli ed Storm storage model.

"simplified"? 4.3:ssa on pointteri, mutta sitä ei tekstissä vielä 
selitetty.

Olisi ehkä hyvä olla kuva ihan stormin yleisestä mallista, ilman
pointteri ym. monimutkaisuuksia.

    In addition to immutable data, Storm has a support for mutable data.

Ei ole totta. Support for immutable data is built on the immutable abstraction.

    In this paper, we discuss only pointers as they are part of the thesis' 
research problems.

Ei tarvitse silloin edes mainita diffejä... mut jos mainitset
sivumennen, PITÄÄ KUITENKIN SELITTÄÄ PARILLA SANALLA MITÄ NE ON.

    Pointer [79] is a semantic-free updatable reference to Storm data block, 
named as Storm scroll block. 

Artikkeli alkuun.
"named as Storm scroll block"????

Oleellista: pointteri *on* myös blokki!

    In practice, pointer is a random string, which resembles Univer- sal 
Resource Names (URN) [15].

Tä?

    Pointer itself doesn't contain any data,

Stranger and stranger...

    it is rather a concept of data.

I thought the previous was really strange. I was wrong. This is worse ;)

    Pointers are created automatically by Storm]

When? How? Why? 

    and each pointer is associated with a collection of pointer blocks.

Created at the same time as the pointer itself? What? 

    Pointer block has a single target for the pointer.

Inside itself it contains the target??

    Pointer block may contain zero or more obsoleted pointer blocks,

So pointer blocks are recursive and can get pretty long???

    i.e., when a new version of scroll block is created, it supersedes one 
older version which has been created in the past.

New version of scroll block????

    The most current pointer block will liobsoletell the pointer block 
targeting the super- seded version.

How?

    Next time, when the pointer is used for referring to a speci c scroll 
block, only the most recent pointer's block target is loaded.

What if I want to see yesterday's version? Impossible?


Eli... 4.3 vaatii *PALJON* työtä jotta lukija tajuaisi mistä
ylipäänsä on kysymys. Käsitteetkään ei näytä olevan ihan
selvillä, kun hypitään blokin, scroll blokin, urn:n jne välillä.
Tämä luku on gradulle hyvin tärkeä koska se on toinen puoli
sitä pointtia joka on gradun sisin. Jos lukija ei tajua,
niin luku 5 on TURHA.


5.

    In this chapter we evaluate Fen re in Peer-to-Peer environment. We
    start by giving a problem overview when considering Fen re in
    Peer-to-Peer environment. We de-  ne Fen re's special needs
    and evaluate existing Peer-to-Peer approaches in light of these
    requirements.

Montako kertaa tuo täytyy tuossa sanoa? Minusta yksi riittäisi ;)

    After that, we propose a system model for Fen re

"System model"?

    and present simple methods to perform data lookups in Peer-to-Peer 
environment.

Should say "required by alph" or something. This is too general a claim.

    As already mentioned in chapter 4, xanalogical document is a lsvirtual  
lelr, in
    which parts of the document are fetched from a global data repository. Thus,
    system imple- menting xanalogical storage model must support global data 
lookups
    ef ciently in order to assemble the lhvirtual  lelr from fragments of data.

Not exactly true. You can have virtual files without any global stuff,
you just always send the relevant scrollblocks along with the document!
Think again.

    In the Fen re system, data fragments are scroll blocks generated by Storm 
storage
    module.

data fragment = yksi merkkikin...
generated by Storm == puppugeneraattori?

    As we discussed

As discussed parempi

    In our scenario, fragments of data is distributed throughout the 
Peer-to-Peer
    overlay network.

Hyvin julma hyppy lukijalle näin äkkiä kesken kappaleen!
Lisäksi "fragments ... *are*".

    We want that user oper- ations in Fen re are location transparent. 

Kielioppi...

    Therefore, our task is to locate and fetch (i.e. obtain) all Storm scroll 
blocks,
    associated to a speci c lpvirtual  lelr from the Peer-to-Peer overlay as ef
    ciently as possible.

Onko? 

Eikös ennemmin niin että haetaan se virtual file ja sitten
sen mukana protokollassa laitetaan tulemaan tarvittavat blokit
jos on?

Tuntuu, että sinulla menee taas scroll block ja block sekaisin.

    In addition to the direct scroll block obtaining using globally unique 
identi er
    of Storm scroll block, we also must sup- port the indirect obtaining of 
Storm
    scroll block using the pointer blocks.

Nimittäin miksi koskaan olisi pointteri *scroll*-blokkiin????

    Our objectives are simple but yet hard to ful ll. First, as a prerequisite 
to
    imple- menting xanalogical storage model in Peer-to-Peer environment, a 
system
    support- ing data lookups must be able to perform global scale lookups. 
Thus, we
    must be able to obtain the Storm block, if it exists in the Peer-to-Peer 
overlay.
    Second, data lookups have to be ef cient, since constructing one lnvirtual  
lelr
    may need obtain- ing several Storm blocks, which are distributed randomly

Tämä tulee nyt uudestaan - rakenne mättää

    Lukka et al. use Freenet [33] as an example Peer-to-Peer system supporting
    globally unique identi-  ers. The work presented in this thesis extends 
their
    work by evaluating different Peer-to-Peer systems more extensively to Fen 
re's
    needs.

Tällä olisi voinut paremmin aloittaa tämän luvun. Tämä kertoo mistä tässä 
jutussa
on OIKEASTI kysymys.

5.2

    For Fen re's needs for locating data, an important advantage of the tightly
    struc- tured approach over the loosely structured approach is that tightly
    structured sys- tems use location-independent, globally unique identi ers 
for
    identifying data in the system.

Öö, eikös tämä ainakin sinun väitteittesi mukaan mene *toisin* päin: kyllähän
gnutellassa voitaisiin käyttää helposti guideja mutta tighteissä ei.
Eli tässä meni logiikka päälaelleen: *onneksi* meillä on guidit joten *voimme*
käyttää tiukkaa.

    Indeed, this feature is similar to Fen re's (and xanalogical storage 
model's) way
    of handling data.

Toistoa - muokkaa jotenkin edelliseen

    Another key feature of tightly structured overlays is that they are able to
    provide general purpose interface for Reference Resolution Services (RRS) 2 
[14].
    Authors argue that next generation RRS must be application- independent and
    references itself should be unstructured and semantically free.

Näistä ei muistaakseni ollut kunnon kuvausta luvuissa 2-3?
Pitäisi jossakin selittää, nyt on taas huono viittaus.

    Fi- nally, as said, with tightly structured systems it is feasible to 
perform
    global data lookups in the overlay.

Kuten sanottiin jo monta kertaa ja vielä kerran?

    To summarize, these aspects may be the most important fea- tures of 
Peer-to-Peer
    infrastructure with regard to Fen re as a distributed, location transparent
    hypermedia system. Thus, we see the tightly structured approach as the best
    alternative to locate data in Peer-to-Peer environment.

Paljon vohvelia....

    Once located, we can use regular TCP/IP-protocols, such as Hypertext 
Transfer
    protocol (HTTP) [54] for fetching Storm blocks from the overlay.

Huono lauserakenne - käännä ympäri

    Current implementation of Fen re uses stan- dard single source downloads 
(HTTP)
    and SHA-1 [124] cryptographic content hash for verifying the integrity of 
data by
    recomputing the content hash for a scroll block.

Current implementation -- eihän P2P vielä toimi, tuo kuulostaa siltä että 
toimisi.

Scroll block?

Kokonaisuudessaan tämä tulee jotenkin ihan kesken tätä juttua tämä siirtymä
downloadeihin... lukija hämääntyy.

Koko download-ongelman voisi sivuuttaa aluksi sanomalla, että kun tiedetään 
mistä
haetaan, niin haku on helppoa, ja siksi keskitytään paikantamiseen.

    However, we believe that these issues are solved,

Uskot, että ne on ratkaistu???

    First, Kademlia's XOR-based distance function is superior over distance 
functions
    of other systems (see section 2.4).

Tuota, tälle et ole missään esittänyt perusteluja, ainakaan kappaleessa 2.4!!!

    Second, there exist already deployed real-life sys- tems using Kademlia 
(e.g.,
    [127, 47, 87, 84]), which means that Kademlia's algorithm is simple and 
easy to
    implement.

Hyvä pointti, mut toinen lause kömpelö; esim. "Secondly, Kademlia is one of the 
only
tightly structured systems that has been deployed in real life([...])"

    On top of Kademlia, we propose the usage of Sloppy hashing [56] which is op-
    timized for the DOLR abstraction of tightly structured overlays.]

Kuvaus taas uupuu tuosta... ei ollut kunnolla siellä 2-3 -luvuissa joissa olisi
pitänyt olla...

    With the Sloppy hashing, we are able to reduce the generation of query hot 
spots.
    Sloppy hashing enables to locate nearby data without looking up data from 
distant
    peers. Moreover, authors' proposal for self-organizing clusters using 
network
    diameters may be use- ful, especially within small groups of working people.
    Thus, with Sloppy hashing we can provide locality properties for the Fen re
    system.

Ja siksi joudut selittämään sitä *tässä*, joka on aivan väärä paikka.

    For better fault tolerance and self-monitoring for Fen re, we propose 
techniques
    presented by Rowston et al. [104]. With these techniques, we can ensure the
    perfor- mance of the Fen re system in a highly adverse conditions, such as 
sudden
    network partition, or highly dynamic and heterogeneous environment.

Tuossa olisi ollut hyvä kuvata jo vaatimuksissa se, että "network partition" on
oleellinen.

    Finally, for more ef cient data transfer, we can use variable techniques 
for this
    purpose. For small amounts of data, HTTP can be used [54]. For big amounts 
of
    data, we can use multisource downloads for better ef ciency and reliability.
    Specif- ically, the technology based on rateless erasure codes [108] seems 
very
    promising.

Ja nyt vielä *UUDESTAAN* sama keskustelu kuin yllä???
Big -> large.

    5.3.2 Methods We use the DOLR abstraction of the tightly structured 
approach,
    i.e., each participating peer hosts the data

Kaikilla on sama data? ;)

    We decided to use the DOLR abstraction in our model, since DOLR systems 
locate
    data without specifying a storage policy explicitly [141].

DOLR toistuu liian monta kertaa - muokkaa edellisen lauseen kanssa.

    DHT-based storage systems, such as CFS [39] and PAST [145], may have severe
    problems with load balancing in a highly heterogeneous environment.

Viite ongelmiin?

    The problem is caused by peers which may not be able to store relatively 
large
    amount of data with a key-value pair, assigned randomly by the mapping 
function
    of the overlay.

Large amount of data with a key-value pair: tosi epäselvä. 
Mainitse, että large block olisi se ongelma.

    These systems waste both storage and bandwidth, and are sensitive to certain
    attacks (e.g., the DDoS attack).

Viite? Miten?

    Additionally, we emphasize that we prefer abstraction level analysis as very
    recently better and better tightly structured algorithms have been proposed.

Tä?

    Thus, we don't want to bind our system proposal to a speci c algorithm de
    nitively as we expect that this development continues.

Aaa... tämän *olisi* voinut mainita ennen kuin alkoi puhua kademliasta tms 
ollenkaan...

    In this model, we use Kademlia's [107] algorithm for locating data in the
    overlay.

In *WHICH* model.

Teksti pomppii aivan kamalasti.

    In the following subsections we assume that we know the structure of the en-
    lade before hand, i.e., when assembling the lhvirtual  lelr we know all the 
Storm
    blocks, which are required to complete the en lade.

Nyt en ymmärrä mitä ajat takaa

    Also, we don't respond to the security issues related to Peer-to-Peer 
systems,
    since there is no working solution available yet;

Tämä on kanssa tosi oudossa paikassa.

    we either assume that Fen re has a reliable technique for identifying 
individual
    entities, or there are no hostile entities among participating peers.

Tä? Miksi? Miten? Miten tämä vaikuttaa?

    In our method, each peer maintains the following data structures for local 
oper-
    ations:

Tällä pitäisi aloittaa uusi kappale siitä, *mitä* operaatioita nyt 
haluttiinkaan.
Ne on sivumennen mainittu jossakin. Lukija ei muista.

    a data structure for listing all key-value pairs which peer maintains; a 
data
    structure for listing all key-value pairs in the chronological order (the 
most
    recent block is topmost) which peer maintains.

peer -> the peer.

En ymmärrä tätäkään lausetta kunnolla.

    We use Storm blocks' identi ers as keys of the overlay.

Which overlay? What about pointers?

    Every key-value pair consists of either a hash of pointer random string 
(pointer
    blocks), or a hash of block's content (scroll blocks) as a key.

Hash of pointer random string????????

block's content (scroll blocks)

Tämä menee *tosi* sekavaksi.

    Finally, we assume that all local operations can be done in a constant time.

Vain sotkee; voi olettaa, että paikalliset operaatiot tehokkaita.

    2. Repeat until the pointer peer is found: each peer forwards the data 
lookup to
    a closer peer which hosts the given scroll block identi er.

Eikös sen DHT-abstraktion pitänyt hoitaa toi vaihe? Miksi se ylipäänsä on tossa?
Kunnon abstraktiotasot puuttuu.

Eli askeleet 2-3 olisivat yksinkertaisesti "query DHT1 for ..."

Kuva 5.1 on turha, koska se on ihan sama kuin dht-kuva aiemmin.

5.2 samoin.

Noista eri operaatioista voisi olla kuva mutta tämä kuvatyyli on huono koska se
toistaa. DHT pitäisi abstrahoida.

    Data lookup with a given pointer random string returning most recent scroll
    block. 

"Pointer random string"?

    5.3.3 Problems Perhaps the most biggest issue in Peer-to-Peer systems is 
the non-
    maturity of security technologies. For instance, online entities cannot be 
identi
    ed safely (e.g., the Sybil attack [46]).

Tota, nyt entities on tullut käytettyä monta kertaa eri merkityksissä...

    For the Fen re system, one security related prob- lem occurs when a user 
wants to
    perform a global data lookup with a given pointer random string; how the 
user is
    able to verify the correctness of the search results, i.e., how she or he 
knows
    which one is the correct Storm scroll block ? The Spam at- tack [117] is a
    variation of previously mentioned problem; data lookup is performed by a 
user,
    but there is no reply from the system. How are we able to know if this was 
a spam
    attack, or the data really doesn't exist in the system ? Another problem 
related
    to the Fen re's security is that if a user downloads data from the network 
to
    local computer and after a network disconnection, user wants to verify off 
line
    the authenticity of data. Obviously, optimal solution to all security issues
    would be that digital signatures are included to every message sent to the 
system
    therefore enabling peers to authenticate other peers safely. However, these
    problems are not only limited to the Fen re system as it concerns all
    Peer-to-Peer computer systems. As security technologies come more mature, 
we wish
    to apply these technologies with Fen re, if applicable.

Sekavaa; lauseet hyppii pahasti.

PKI ja certit jäi käsittelemättä...

    We point out that each of these sub-categories have number of open 
problems, in
    which there are no solutions yet, or solutions are only partial.

Aivan turha lause

    Then, we focused our attention to the Fen re system.

Samoin.

    In the last chapter, we evaluated existing Peer-to-Peer approaches with 
regard to
    Fen re's needs. We see that the tightly structured approach is the best
    alternative to Fen re's needs for the following reasons. First, Storm,
    xanalogical storage model and tightly structured systems use global unique 
identi
    ers for identifying data. Second, our Storm design uses semantic-free 
references
    (block identi ers and pointer random strings) for locating data in 
distributed
    networks. As the authors of [14], we also agree that references should be
    semantically-free in next-generation reference resolution services. Third, 
by
    using the DOLR abstraction of tightly structured over- lay, we can minimize 
the
    lack of locality in the tightly structured approach. Finally, we believe 
that
    issues related to tightly structured overlays are solved in the near future,
    because of wide and intensive co-operation among research groups.

Kuten yllä: toi eka ei ole syy

Määrittelitkö semantic-free:tä missään?

Minimize lack of locality - miten?

    In the following months, we will implement a Fen re Peer-to-Peer prototype.

Ei hyvä tyyli sanoa noin.