Dear OpenAFS community and developers,

I hope this email finds you all well.

My name is Alex (Zhengfei Li), a graduating Computer Science major from
Swarthmore College. I am writing to reach out regarding my Google Summer of
Code proposal titled "Netcat for Rx".

In my proposal, I plan to develop a Netcat-like command-line utility for Rx
and provide a simple tool for developers to test connectivity, debug, and
automate tasks. I would greatly appreciate any feedback or guidance on the
status of this project and my proposal. Specifically, I am eager to
understand:
- unique aspects of Rx that demand special attention
- suggestions on the tool's scope
- any potential pitfalls I should be aware of

Thank you very much for your time reviewing my proposal. I am open to any
feedback, engaging with you, and refining my proposal with your expertise.

Best,
Alex

<--- Below is the plain text of my proposal --->
# Biography

Greetings! I'm Alex, a graduating Computer Science major from Swarthmore
College, passionate about file systems and networks projects.
This fall, I will be joining the Carnegie Mellon University MSCS program,
eager to explore deeper into networking.

I have completed courses in OS and Computer Networks, gaining a robust
understanding of file systems, TCP/UDP, and socket programming with C and
Python. In my "Simple Firewall" course project, I extensively used netcat
for tasks like debugging with manual protocol interactions and setting up
simple servers or listeners to test firewall rules. This experience greatly
improved my understanding of network security and my skills in network
analysis and troubleshooting.

Familiarizing myself with the Rx protocol, I achieved a primary
understanding that Rx is a connection-oriented protocol that operates over
UDP and supports service multiplexing. I explored tools like `rxgen' and
`rxdebug', though I have not yet used it productively. I am a quick learner
and I am confident that I can convert my theoretical knowledge into
implementation practices in days.

I have work experience related to software. During the summer of 2023, I
joined a Computer Education research team and collaborated on developing an
interactive online exercise webpage based on an open-source project
Runestone. I took a lead in program design and this experience also
involves navigating extensive code bases, enhancing my ability to
comprehend and contribute to large projects. The website is already live,
with functionalities receiving acclaim from our faculties and students. In
the summer of 2024, I worked as a Business Data Analyst intern at SETVI, a
SaaS startup, where I greatly improved my communications and formalized my
documentation practices.

I am passionate about contributing to OpenAFS through the `netcat for Rx'
project, observing it as a natural extension of my academic and personal
interest. I really look forward to working with the community, learning
more about OpenAFS, and developing tools for Rx-based services.

## Availability

I plan to start this 12-week project on June 16, with a commitment of
around 8 hours each weekday. In addition, I have daily family obligations
of around 3 hours and allocate 1 hour daily to exercise. During the
weekends, I plan to spend 5 hours on prototyping a startup idea.

# Project Information

## Netcat for Rx

OpenAFS uses RxRPC to support the distributed files system, which provides
reliable ordered message delivery, multiplexed channels and built-in
security features. However, there are no simple command-line utilities for
Rx network debugging and investigation. This project proposes to build a
netcat-like tool for Rx protocol. This would fill the gap in the current
toolset for OpenAFS administration and development community.

For the functionalities of `netcat for Rx', we hope to achieve the
following objectives:
    -Test Rx network connectivity (e.g., with echo request)
    -Debug Rx interactions
    -Automate tests particularly for OpenAFS services.
    -Rx server and listener emulation

Considering the massive amount of requests, C programs with tight time and
space complexity would be designed for performance. I plan to draw from
established netcat sources and use cases (like port scanning) and design
comparable utility functionalities. In addition, I would also investigate
unique features of Rx (like channel multiplexing) and devise helpful tools
with reference to developers' daily experiences and demands.

## Project Schedule and Deliverables

Following is a tentative plan with a duration of 12 weeks. For each phase,
I summarized the objectives and the deliverables.

### Week 1-2

Objectives:
    -Conduct research on Rx protocol (and ideally gather user demand for
the toolset)
    -Review netcat functionalities and code bases
    -Finalize the scope of features to be completed in 12 weeks

Deliverables:
    -Scoping document of functionalities

### Week 3-6

Objectives:
    -Design the tool architecture and develop a command-line interface
prototype
    -Iteratively improve the design based on the project scale and feedback

Deliverables:
    -A documentation of functionalities with design
    -Code for prototype

### Week 7-10

Objective:
    -Implement the features
    -Implement ``simple'' unit tests for individual features

Deliverables:
    -Code for implementation
    -Unit test report for features

### Week 11-12

Objectives:
    -Finalize the implementation
    -Conduct thorough testing that simulates a typical developer workflow
    -Finalize the documentation
    -Prepare for project evaluation

Deliverables:
    -Complete code base
    -Comprehensive test files streamlining use cases
    -Complete user documentation and maintainer documentation
    -Final project report if needed

## Test Plan

For each individual functionality, my unit tests will cover:
    -each individual modules
    -command line interface
    -memory safety

For holistic testing, I plan to simulate a typical workflow of a developer
by:
    -Simulate an OpenAFS environment
    -Stress testing the tool with high volumes of requests, incomplete
requests and more to evaluate robustness
    -Evaluate program performance
    -Verify the accuracy of output presentation
    -Improve upon feedback

Reply via email to