How to control the replication rate in simulator?

Home Forums PeerfactSim Forum How to control the replication rate in simulator?

This topic contains 11 replies, has 1 voice, and was last updated by  Kalman 3 years, 2 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #918

    Anas Anis

    According to the theoretical description of GIA, the replication rate
    has some effects on the performance of the overlay, but how to control
    this rate in the simulator?

    #919

    Matthias Feldotto

    At the moment only an one-hop replication of documents to all neighbors is implemented. Therefore all nodes store replicated content from neighbors locally. Instead of one-hop there are many strategies (for example with a parameter for the replication rate) imaginable, but not yet implemented. Feel free to implement them yourself if you want to use it.

    As entry point you find the implemented strategy in the class de.tud.kom.p2psim.impl.overlay.gnutella.gia.OneHopReplicator.

    #920

    Anas Anis

    I thought the replication rate is something different from the one-hop
    replication! I thought the replication rate is the replication of
    documents inside the overlay, but the one-hop replication is like
    pointers of the direct neighbors’ contents and not the contents
    themselves. so the replication rate has nothing to do with neighbors!
    (this is what I understood)

    #921

    Anas Anis

    So am I right?

    #922

    Anas Anis

    another question concerning GIA, i’m getting results of ‘average hop
    counts’ when simulating this overlay around 0.5. What is the meaning
    of having 0.5 as number of hops? I expected the number of hops to be
    at least 1 or more.

    #923

    Matthias Feldotto

    The implemented One-Hop replication provides (java class comment)

    * Component that manages the one-hop replication of documents to all neighbors and stores replicated
    * content from neighbors locally.

    I’m not deep in the topic of GIA, but another replication is not yet implemented. So if you need other replication you have to implement it yourself

    #924

    Matthias Feldotto

    The average hop count could also be less than 1, because if the key is managed at the local node there will be a hop count of 0 for this request.

    #925

    Anas Anis

    Thanks for your reply.

    I have another question, but this time about Gnutella0.4. How can I
    simulate the failure (or leaving) of Gnutella0.4 nodes inside the
    simulator?
    I’m using GnutellaApplication as the componentClass in the
    configuration file. In GnutellaApplication there is no fail or leave
    functionality to be called. So how to simulate such a scenario?

    #926

    Matthias Feldotto

    To simulate the leaving of hosts you have two possibilities:

    1. Let a node leave the network by using the leave() or fail() methods
    of the GnutellaOverlayNode class (These operations are implemented not
    in the application because they are direct functions of p2p nodes).
    2. You can use a ChurnGenerator (see different example configurations).
    It provides the leaving and joining of nodes depending on different
    random models.

    Depending on your scenario one of these options should help you.

    #927

    Anas Anis

    I would like to use the first possibility because the second (churn)
    doesn’t offer me a permanent leave of nodes (I think it works like
    restarting nodes). But how to use these functions if I’m using
    GnutellaApplication? or can I use the GnutellaOverlayNode instead of
    GnutellaApplication? I searched for an example like that, but I didn’t
    find, and I tried to make my own example and I failed because I
    couldn’t write an action for connecting nodes.
    Thanks

    #928

    Matthias Feldotto

    You can use methods from more than only one class in your action file.
    Look for an example in the configuration
    “config/application-filesharing2/FSChord-32_Peers.xml” of the current
    simulator’s version. The classes are named by the attributes
    “componentClass” and “additionalClasses”. You can use methods in the
    actions file with “class:method” (compare the actions-file for the
    example).

    #929

    Kalman

    Churn offers also a the option for permanent leave, in the case the
    the rate of joining nodes is lower than the rate of failing nodes.
    As Matthias said, Churn is affecting the network layer of the nodes,
    not the application or overlay layer, so you should check the commands
    for the network layer. Have also a look at the Chord example, as it
    demonstrates how to set up the commands to make nodes leave your
    network. However, it is necessary to digg into the code to see how the
    actions in the actions file take effect in order to understand, how to
    use them properly.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.

Comments are closed