[Gzz] Re: [Gzz-commits] storm/doc/pegboard/attacking_gisp--hemppah peg.rst

[Tuomas Lukka]

> There are two variations of this scenario. The first
> +variation is the static scenario in which peers do join or leave the system 
> while
> +the test is running. In the second variation, peers can join and leave the
> +system while the test is running. 

You're missing a negation somewhere, I think.

> +We expect that GISP is able to route some queries to their destination peers 
> eventually,
> +altough the performance of a lookup is expected to decrease. 

How do you suppose that will happen? 

You need to study the algorithms in GISP and explain how it will go.

Also, you need to estimate what you expect to find beforehand.

> Also, we except that
> +some of the queries are lost. With this test case, we wish to get more 
> information
> +how big the lost rate is. 
> +
> +Simulation Process: 
> +- Create 90 normal peers in the network (ID is in the format "peer1 -peer90")
> +- Create 10 "dumb" peers in the network (ID is in the format "dumb1-dumb10")
> +- If necessary, the number of "dumb" peers can be changed (for more 
> "clearer" 
> +  analysic etc)

This is not good - we want to understand
the scaling with both network size and dumb peer fraction.

> +- Create 100 data items in the network (the format is "key1-100", 
> "value1-100")

Not good - several of the peers will have no items. I'd recommend enough
to have a good probability that each peer will have its own items.

> +- Perform 100 queries randomly (random peer selection (1-100) and random 
> query 
> +  selection (1-100)) with *normal* peers

100 is rather little if the routing tables &c are expected to morph
during the experiment.

> +- Update all peers' routing information every loop pass 

How realistic is that? What changes will there be, if the network
itself is static?

        Tuomas