Dear OpenAFS community and developers, I hope you all are doing well. I wish to follow up on my previous email regarding my proposal for Netcat for Rx.
After discussing with GSoC Alumni, I got great advice on that I can show my skills and understanding of the project through a review of the source code. Therefore, I am writing to follow up with my edited proposal with a dedicated part demonstrating my understanding. When you have a moment, could you help me review my new proposal? I am really looking forward to your guidance and contributing to OpenAFS in the future! Best, Zhengfei Li (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 robust understanding of file systems, TCP/UDP, socket programming with C and Python. In the "Simple Firewall" course project, I extensively used netcat for tasks like debugging with manual protocol interactions and setting up simple server 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, and explored tools like `rxgen' and `rxdebug', though I have not yet used them productively. As a quick learner, I am confident converting my theoretical knowledge into implementation practices in days. I have work experience related to software. During summer 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 acclaims from our faculties and students. In summer 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 around 8 hours on 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. \newpage # 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 is 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 program 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 into unique features of Rx (like channel multiplexing) and devise helpful tools with reference to developers' daily experiences and demands. ## Background Understanding of Source In an effort to prepare for the development, I performed a review and research on both RxRPC implementation as well as the canonical netcat source code. A summary of my understanding is provided below: ### Understanding RxRPC With reference to rxrpc.rst, RxPRC is a reliable two-phase protocol built on UDP. The purpose is to create virtual network connections such that operational or control data and messages could be sent to the Andrew File System. The protocol adopts two-layer design using both session layer (for connections) and presentation layer (for conversion of data format). The two-phase protocol operation requires clients sending request blob, server processing requests, server replying, and clients receiving a blob of reply. The architecture supports multiple virtual connections sharing the same transport endpoint, with each connection identified by 7 parameters (local/remote addresses, ports, direction, connection ID, service ID). For reliability, both hard-ACK and soft-ACK are available. For API, we can use AF\_RXRPC with control messages like RXRPC\_USERCALL\_ID, RXRPC\_ABORT as metadata. I also focused on source code like af\_rxrpc.c and ar-internal.h, and I gained a better idea of internal resource management, structured data handling, protocol mechanics and error handling. Such information contributes to my following understanding of this project: - Map RxRPC’s internal state management to a simplified interface that can be controlled via command-line options. - Utilize RxRPC data structures and error-handling patterns to ensure that the new RxNetcat tool behaves predictably even under adverse network conditions. - Design test cases that mirror real-world scenarios in RxRPC communication, thereby reinforcing the tool’s reliability and diagnostic value. ### Understanding netcat Reviewing the netvat.c, I am again amazed by the compact yet versatile commandline utility supporting the operations from both client and server. Following is some of my observations that I hope to adopt in my future development: - Option Parsing and Configuration: processing command-line with standard libraries like getopt.h enables user-friendly and extensible functionality. Therefore, our RxNetcat can have operational flags for details indictating whether the tool connects to a remote host or listens for incoming connections. - Socket Management and I/O Multiplexing: Netcat’s implementation of socket creation, connection, and data relay (via loops using select() or poll()) serves as an excellent model for building similar functionality tailored to Rx. This pattern is crucial for ensuring that the tool can handle multiple simultaneous I/O operations, which is particularly relevant given Rx’s multiplexed channel capabilities. - Error Reporting and Resource Clean-up: The emphasis on graceful error handling and proper resource deallocation in netcat’s codebase has informed my approach to developing robust and maintainable code. ### Implications By synthesizing these approaches, the project will: - Adapt netcat’s straightforward, reliable network handling to work with Rx’s unique protocol features such as channel multiplexing and built-in security. - Enable diagnostic features like echo requests and connection tracing that reflect both the simplicity of netcat and the complexity of RxRPC. - Provide a foundation for automated testing and stress evaluation by mirroring netcat’s efficient I/O loop structure in an environment tailored for Rx. ## 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 On Thu, Mar 27, 2025 at 11:55 AM Zhengfei Li <[email protected]> wrote: > 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 >
