Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- project:hgg:open_tasks:software:p2p_networking [2012-01-23 16:56] – kezl
+++ project:hgg:open_tasks:software:p2p_networking [2012-07-26 12:43] (aktuell) – alte Version wieder hergestellt 91.203.212.124
@@ Zeile 10: / Zeile 10: @@
   * levels of quality (wan, lan, bybrid)
   * substitute player for calculations (=> failsafe, less rework)
-====== Isaac's comments ======
-There are two main sub-projects associated with the development of a P2P
-network for HGG: one dealing with hardware and one dealing with software.
-It is also important to remember that there is a difference between a mesh
-network and a P2P network: http://p2pfoundation.net/Mesh_Networks . That
-distinction is probably important for the hardware component.
-I am planning to concentrate on the software component.
-As developers we can either modify an existing open-source network
-and customize it to fit our needs or build everything from scratch. I am in favour of the
-latter since none of us has a deep knowledge of P2P networking and programming.
-Starting from fundamentals would allow us to learn about technologies gradually
-instead of drowning in the sea of code from a huge open-source project.
-My plan would be to start with one of the simpler protocols described in the many
-papers on the subject, for example Chord, which was one of the first in existence.
-Once we have successfully created a network based on this protocol, we will be in
-a position to extend it and adapt it further because of the knowledge we will have
-gained. Even if libraries exist for these protocols, I still think it is worthwhile
-trying to implement a working version ourselves first.
-On the other hand, if we were to modify an existing network, then I would be inclined
-to choose one of the file-sharing networks (as opposed to networks like Skype, streaming
-video). These will most likely have the models and infrastructure necessary for our
-needs. Since we are trying to save time with this method, I would deliberately choose
-one of the more advanced networks to try and get the most "bang for the buck"
-regarding features. I do not think we should let the complexity of a particular
-system put us off – all of these networks are complex enough anyway, so a little more
-cannot hurt. It is also important to note that the most successful networks, such as
-Skype, are closed source anyway.
-Anyway, this would definitely be possible and we may even see faster gains in the beginning,
-but it would be important to extract only the code and modules that we actually need.
-I feel that large chunks of code may be unnecessary for our project, but we would be
-forced to leave them in because we might not truly understand how they work.
-I am not the project leader, but unless anyone has objections, then for the moment,
-my immediate short-term plan is to start implementing the Chord protocol in C.
-It will be necessary to write cross-platform code, but I think this can be dealt with as time
-goes on. Once a basic protocol is working, then I will see where I can go from there.
-I have created a source code repository for this here: https://github.com/kezl/Pond .
 hadez' comments: