Concept for Distributed Simulations using iSIGHT

1
A P2P network traffic andaccess control
protocol Herwig Unger Albert Einstein-Str. 23,
18051 Rostock, Germany Phone [phone],
Fax [phone] E-mail hunger_at_informatik.un
i-rostock.de
2
Motivation

• decentralized P2P system recently gained an
  increasing popularity due to a lot of
  advantages
• communities are built on the base of such
  systems reflecting it its structures the social
  relations between ist users
• however, contents is offered only by a small
  group of users e.g. 5 of all machines host
  70 of all contents
• offering contents is not attractive for the
  users, since hereby a lot of bandwidth is taken
  to answer remote users request
• lurker and freerider mostly take advantage from
  such systems

Powerful control mechanisms are needed to control
trafficand access of resources
3
Ideas what can be done with virtual money

• Special services (not standard services like
  search) and information are only available for
  an additional payment.
• High priorities for the service execution are
  given for additional payment, since these
  priorities may cause shorter answer times.
• Bandwidth will be limited. Standard user
  communication is either done with a small
  percentage of the available communication
  bandwidth or only available, if the network load
  is not to high.
• Hopcounters of message chains are lower for
  standard users. Therefore, standard users may
  not see the whole size of the network and cannot
  access to all available information.

4
Requirements to virtual money

1. An amount of money represented through tokens
   must be generated in the community.
2. The amount of money must be adapted to the
   number of community members and therefore the
   potential to offer services/resources in a
   community.
3. Fault tolerance and copy protection must be
   provided by decentralized algorithms.
4. Safe trading mechanisms must be described

Virtual money on the base of a token population
shall be used with a respective transmission
protocol
5
Building trust

• Trusted third authorities (machines)
• Duration of mutual relations possibility to
  predict the others behavior
• witnesses, control by a group of other
  machines e.g. trust chains

6
Control of the token amount f(community_memb
er)

• The number of tokens in the population can be
  controlled with a decentralized mechanism.
• Every node generates and kills tokens depending
  on the average time between the visits of 2
  tokens.
• The existing number of tokens is an almost stable
  value over the time and depends from the number
  and characteristics of the community members.

Statistics of the token population
7
Statistics for the amount of money

• Tokens removal means to destroy money, which is
  owned by one of the community members.
• Even if the monetary value is small, too large
  lost / win by this process must be avoided.
• Since the process is done pretty randomly, the
  and - are well balanced for every node of
  the community over a linger time.

Statistics difference between token generation
and removal for every node
8
The token structure
9
The copy safe protocol for money token
Machine i
Machine i-K (witness)
Machine iK
FWD_witness
K2
Acknowledge RCV
FWD_i1
Acknowledge FWD
Acknowledge FWD_i1
Time
logical transfer
physical transfer by protocol
a) Forward (FWD) Protocol
b) Token transmission realized by the protocol
10
Analysis I

1. The probability that k nodes are active is
2. The probability that a machine is in the network
   is not equallydistributed over the whole day. It
   will be significantly higher a few moments after
   the time when it has been already seen in the
   network.
3. The exponential distribution can be used to model
   this stochastic lifetime problem.
4. If a computer ci has been a member of a community
   at time ti, the probability p(ci) that it is
   still connected with this community at time t'i
   (with ti lt t'i) is given by

where is equal .
11
Analysis II
5. Therefore, the probability p(n) that at least
n of K machines are available after some times is
given by
what can be estimated for equal, average
transmission and processing times by
with
30 machines are a good compromise
12
Fault tolerance

• In case the of no response of the owner node x,
  the token will be forwarded to the next node
  without replacing x for a fixed set of L cycles
  i.e. in case x joins the community in this time
  again, it will still have access to its coin.
  After L cycles the money is assigned to any node
  from the history.
• If one other node i-K does not respond, i-(K-1)
  will be used instead. All predecessors j in the
  history, ji-(k-1) (1) i-1, will be put on
  position j-1 and for position i-1 a randomly
  selected, new node will be contacted and obtain
  the needed information of the token. For
  security reasons, this replacement can be done
  for limited number of nodes in the history,
  only.
• Every owner of a token may keep a copy his
  tokens. In case one of the tokens is not
  returned to its owner within a timeout interval,
  it may use the copy to contact all nodes kept in
  the history, find out the place of loss an
  re-initiate the respective token game.

13
Trading

• The owner crypts his own and the IP address of
  the receiver (typically with its private key) and
  put it on the token.
• 2. The new owner is set as the successor of the
  old owner in the forward cycle.
• 3. The token pass another cycle over the new
  owner and K-2 randomly selected machines.
• 4. The machines along the history trail check the
  authenticity of the token and store the old and
  new owner information.
• 5. For a second cycle, the old owner adds again
  the new owner as its sucessor.
• 6. Now, the new owner replaces the two IP
  addresses attached by its own (crypted with its
  provate key), only. This change can be confirmed
  by the nodes of the history, since they do know
  both addresses from the last cycle.
• 7. The token forward will be continued with the
  new owner (i.e. a new node, where the token
  return to after K-1 steps).

14
Network traffic control

1. tokens are used.
2. the number of tokens will be controlled by all
   community members in a decentral manner, again.
3. the tokens are not used as money but as PERMIT
   to transfer messages or data ackages with a fixed
   size.
4. tokens use the before introduced protocol,
   messages / date may be sent directly.
5. from community members, only incoming messages
   authorized by tokens are accepted.

15
Conclusion

• The introduced probabilistic money system may
  control access and traffic in P2P communities in
  a fair manner.
• The user do not see the trading activities but
  the knowledge about its existence may force him
  to contribute resources.
• The properties of the payment system differ from
  real money.
• The developed protocol ensures probabilistically
  security and copy protection for the money
  tokens.
• On top of a non-stable community a stable
  structure is built, which probably can be used
  for other applications, too.

16
Thank you for your attention !
Contact Herwig Unger FB Informatik, Universität
Rostock D-18051 Rostock Email
hunger_at_informatik.uni-rostock.de Telefon 49 381
498-3355