Resource Sharing Community

Introduction

Currently, the only thing that a computer can do is to process information. In the last project, the FSC, a community member can share its information (in the form of files) to any other members. In this project, we hope that the computation power of a member can also be shared with others. That is, the sharable objects that we would like to share include not only files but also computation power. Computation power could be shared in many forms. For example, a community member could provide a certain kind of service to contribute its CPU to the community. Any one who needs a certain kind of service could ask service providers for help. Or a member could donate its computation power by running executables received from others. Hence here comes the concept of “Resource Sharing Community.”

Resource sharing community (or RSC for brevity) is basically a file sharing community with extra capabilities that support more resource types. That is, in addition to sharing files, an RSC member can also donate its computation power to the community. A RSC member shares its resources by providing services. The default service that any RSC member must provide is “file sharing.” We can think of FSC as a special RSC in which all members provide only the default service.

In addition to the default service (file sharing), we define two more basic services that an RSC member must provide. And the requirements for these services are described in the following section. In fact, an ultimate goal of RSC is to enable a myriad of services, no matter they are designed specifically for RSC or third party applications, to be shared to the community with minimum effort.

Requirements for sleeper and grep

In addition to file sharing, the two must-have services that an RSC member has to provide are sleeper and grep. A sleeper is a daemon process that does nothing useful but only sleeps; grep is a useful pattern matching tool that is commonly available in Unix-like platforms, but unfortunately it is not so common in WIN32 platforms. Note the essential differences between these two services: sleeper is a daemon process that is specifically designed for RSC while grep is a third party application that exists in the form of executable file.

sleeper

1. A sleeper is a daemon process that is designed and implemented specifically for RSC. When it accepts a request, it sleeps for a period of time (as the request instructs), and returns a result back to the requester. The result contains the IP’s of both the requester and the service provider, the time the sleepers starts to sleep, the time the sleeper stops sleeping, and the total time the sleeper sleeps for the request.

2. A sleeper can serve multiple requests at the same time.

3. A member could query some other member if he/she is a sleeper provider.

4. A member could search the community for sleeper providers.

5. After finding out sleeper providers, a member can put them into a group. Users can name/rename the group.

6. A member can ask a remote sleeper to sleep for a specific period of time by sending a request to the sleeper provider.

7. A member can announce that it provides the sleeper service (and therefore becomes a sleeper provider).

8. A sleeper provider can reject requests from other members if its sleeper sleeps too much.

9. When a sleeper provider receives a request, it can serve the request by itself, or relay the request to another sleeper provider (if it knows any).

10. A request to a sleeper provider cannot infinitely travel around among different sleeper providers. It will be either served or dropped by some sleeper provider in a finite period of time.

11. A sleeper request can be issued either from user interface (interactive mode) or from script files (batch mode).

grep

1. A member could query some other member if he/she is a grep provider.

2. A member could search the community for grep providers.

3. After finding out grep providers, a member can put those grep providers into a group. Users can name/rename the group.

4. A member can ask the grep provider to grep a single file for a specific string pattern.

5. A member can ask the grep provider to grep multiple files for a specific string pattern.

6. A member can ask multiple grep providers to grep multiple files for a specific string pattern.

7. A member should be able to merge results returned from different grep providers.

8. A member can announce that it provides the grep service (and therefore becomes a grep provider).

9. A grep provider can accept grep requests from other member, process the requests, and send the results back. In addition to grep output, the result should also contain the IP of the grep provider.

10. A grep provider can also reject grep requests if its workload is too heavy.

12. When a grep provider receives a request, it can serve the request by itself, or relay the request to another grep provider (if it knows any).

13. A request to a grep provider cannot infinitely travel around among different grep providers. It will be either served or dropped by some grep provider in a finite period of time.

14. A grep request can be issued either from UI (interactive mode) or from script files (batch mode).

15. Users can run shell commands either from UI or from script files. Users can ask a remote grep provider to grep a specific string pattern from that shell command output.

Other services

In addition to sleeper and grep, there might be some other services that could be provided to the community. It should be easy enough for a member to provide new services, no matter they are designed specifically for RSC or third party applications.