From Fedora Project Wiki

No edit summary
Line 22: Line 22:
#**Reduced latency: A trivial update will allow a node to compute what is out of date without any additional network traffic.
#**Reduced latency: A trivial update will allow a node to compute what is out of date without any additional network traffic.
#Poject overview
#Poject overview
#*The work process of CHASM is quite different with rsync. When the file updating is made on the master, the master will creates a new manifest which describes the state of the file structures and includes the hash values of files. The manifest is published to the tracker. The tracker performs a role similar to that of a bittorrent tracker and is responsible for distributing the new manifest. Non-master nodes periodically query the tracker for new manifests (and more peers for incomplete manifests) to check whether its local mirror is up to date.
#*The only structure enforced on the network is that of a directed graph in which no edges flow into the master node. An arbitrary node x can be the upstream to y while at the same time fetching updates from y (and thus it is downstream as well).
# What will be done
# What will be done
#*Implementation of the peer-to-peer network protocol. This protocol resembles a "stateful HTTP" as one of our members put it. It takes into account the state of the upstream's pool and cache to allow clients to maximize throughput. Including the following aspects:
#*Implementation of the peer-to-peer network protocol. This protocol resembles a "stateful HTTP" as one of our members put it. It takes into account the state of the upstream's pool and cache to allow clients to maximize throughput. Including the following aspects:
Line 28: Line 30:
#**File transfer protocol.
#**File transfer protocol.
#*Implementation of a generic message-passing framework for Unix domain sockets including the following functionalities:
#*Implementation of a generic message-passing framework for Unix domain sockets including the following functionalities:
#**The ability to communicate with daemons effectively.
#**The ability to communicate between daemons effectively.
#**The ability to transfer file descriptors easily.
#**The ability to transfer file descriptors easily.
#*Partial design and implementation of a peer-tracker protocol. Once the peer-to-peer protocol is complete we will be turning our attention to the peer-tracker protocol. We have not put nearly as much attention into this as the peer-to-peer protocol as it is less critical.
#*Partial design and implementation of a peer-tracker protocol. Once the peer-to-peer protocol is complete we will be turning our attention to the peer-tracker protocol. We have not put nearly as much attention into this as the peer-to-peer protocol as it is less critical.

Revision as of 06:22, 19 May 2010

For information how to complete this form, refer to Summer Coding 2010 step-by-step for students.

Random list of application requirements

  1. Must include a schedule that was worked out with mentor
  2. Keep on eye on the Talk: page that is associated with the proposal page you create. Click on the discussion link on the top of your proposal page. The Talk: page is where mentors comment on your proposal.
  3. Make sure you have clicked on the watch link on the top of your proposal page(s) and Talk: page(s). Use the link to my preferences at the top of the page to set your Watchlist preferences to email you when changes are made.

About you

  1. What is your name?
    • Wang Fang
  2. What is your email address?
    • wangfangcs@gmail.com
  3. What is your wiki username?
    • wangfang
  4. What is your IRC nickname?
    • wangfang
  5. What is your primary language?
    • Chinese, second language English
  6. Where are you located, and what hours do you tend to work?
    • Hubei, China. UTC+08:00, 10:00 ~ 23:00 in UTC+08:00.
  7. Have you participated in an open-source project before? If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?

About the project

  1. Project information
    • The name of my project is CHASM. The idea page is https://fedoraproject.org/wiki/Summer_Coding_2010_ideas_-_CHASM.
    • CHASM stands for the Cryptographic-Hash-Algorithm-Secured Mirroring solution, and provides the following improvements to the current alternatives:
      • Uses SHA2 to uniquely identify files: Each file is stored by SHA2 and hard-linked into place on the filesystem.
      • Cache-aware transfer protocol: When an upstream and a downstream node synchronize, they take care not to invalidate the filesystem cache of the upstream in order to minimize disk writes.
      • Reduced latency: A trivial update will allow a node to compute what is out of date without any additional network traffic.
  2. Poject overview
    • The work process of CHASM is quite different with rsync. When the file updating is made on the master, the master will creates a new manifest which describes the state of the file structures and includes the hash values of files. The manifest is published to the tracker. The tracker performs a role similar to that of a bittorrent tracker and is responsible for distributing the new manifest. Non-master nodes periodically query the tracker for new manifests (and more peers for incomplete manifests) to check whether its local mirror is up to date.
    • The only structure enforced on the network is that of a directed graph in which no edges flow into the master node. An arbitrary node x can be the upstream to y while at the same time fetching updates from y (and thus it is downstream as well).
  3. What will be done
    • Implementation of the peer-to-peer network protocol. This protocol resembles a "stateful HTTP" as one of our members put it. It takes into account the state of the upstream's pool and cache to allow clients to maximize throughput. Including the following aspects:
      • Peer negotiate and discovery protocol.
      • Manifest transfer protocol.
      • File transfer protocol.
    • Implementation of a generic message-passing framework for Unix domain sockets including the following functionalities:
      • The ability to communicate between daemons effectively.
      • The ability to transfer file descriptors easily.
    • Partial design and implementation of a peer-tracker protocol. Once the peer-to-peer protocol is complete we will be turning our attention to the peer-tracker protocol. We have not put nearly as much attention into this as the peer-to-peer protocol as it is less critical.
  4. Timeline
  5. Experience
    • I am good at Linux netwrok programming. I have participated several netwok related projects including web proxy, NAS(Network Attached Storage), distributed file system(http://code.google.com/p/dpfs/), implement TCP UTO(RFC5482) in Freebsd kernel(gsoc2009 project). I am familiar with network programming paradigms including multi-thread, multi-process, event-base.

You and the community

  1. If your project is successfully completed, what will its impact be on the Fedora community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Fedora community, at least one of whom should be a Fedora Summer Coding mentor. Provide email contact information for non-Summer Coding mentors.
  2. What will you do if you get stuck on your project and your mentor isn't around?
  3. In addition to the required blogging minimum of twice per week, how do you propose to keep the community informed of your progress and any problems or questions you might have over the course of the project?


Miscellaneous

  1. We want to make sure that you are prepared before the project starts
    • Can you set up an appropriate development environment?
      • Yes.
    • Have you met your proposed mentor and members of the associated community?
      • Yes.
  2. What is your t-shirt size?
    • L