[OpenAFS-devel] [GSoC Proposal FollowUp] Netcat for Rx by Zhengfei Li (Alex)
Zhengfei Li
zhengfeili.alex@gmail.com
Fri, 4 Apr 2025 14:55:48 -0400
--000000000000f8008a0631f86f77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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=E2=80=99s 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=E2=80=99s reliability and diagn=
ostic
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=E2=80=99s 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=E2=80=99s multiplexed channel capabilities.
- Error Reporting and Resource Clean-up: The emphasis on graceful error
handling and proper resource deallocation in netcat=E2=80=99s codebase has =
informed
my approach to developing robust and maintainable code.
### Implications
By synthesizing these approaches, the project will:
- Adapt netcat=E2=80=99s straightforward, reliable network handling to wor=
k with
Rx=E2=80=99s unique protocol features such as channel multiplexing and buil=
t-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=E2=80=99s efficient I/O loop structure in an environment t=
ailored
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=E2=80=AFAM Zhengfei Li <zhengfeili.alex@gmail=
.com>
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 o=
n
> 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 great=
ly
> 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 ove=
r
> UDP and supports service multiplexing. I explored tools like `rxgen' and
> `rxdebug', though I have not yet used it productively. I am a quick learn=
er
> 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. I=
n
> 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 m=
y
> 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 provide=
s
> reliable ordered message delivery, multiplexed channels and built-in
> security features. However, there are no simple command-line utilities fo=
r
> 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 an=
d
> 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 tool=
s
> 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 feedba=
ck
>
> 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 develope=
r
> 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
>
--000000000000f8008a0631f86f77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Dear OpenAFS community and developers,<br=
></div><div dir=3D"ltr"><br></div><div>I hope you all are doing well. I wis=
h to follow up on my previous email regarding my proposal for Netcat for Rx=
.</div><div><br></div><div>After discussing with GSoC Alumni, I got great a=
dvice 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.</div>=
<div><br></div><div>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=C2=A0future!</div><div><br></div><div>Best,</div><div>Zheng=
fei Li (Alex)</div><div><br></div><div><--- Below is the plain text of m=
y proposal ---></div><div># Biography<br><br>Greetings! I'm Alex, a =
graduating Computer Science major from Swarthmore College, passionate about=
file systems and networks projects.<br>This fall, I will be joining the Ca=
rnegie Mellon University MSCS program, eager to explore deeper into network=
ing.<br><br>I have completed courses in OS and Computer Networks, gaining r=
obust understanding of file systems, TCP/UDP, socket programming with C and=
Python. In the "Simple Firewall" course project, I extensively u=
sed netcat for tasks like debugging with manual protocol interactions and s=
etting up simple server or listeners to test firewall rules. This experienc=
e greatly improved my understanding of network security and my skills in ne=
twork analysis and troubleshooting.<br><br>Familiarizing myself with the Rx=
protocol, I achieved a primary understanding that Rx is a connection-orien=
ted protocol that operates over UDP and supports service multiplexing, and =
explored tools like `rxgen' and `rxdebug', though I have not yet us=
ed them productively. As a quick learner, I am confident converting my theo=
retical knowledge into implementation practices in days.<br><br>I have work=
experience related to software. During summer 2023, I joined a Computer Ed=
ucation research team and collaborated on developing an interactive online =
exercise webpage based on an open-source project Runestone. I took a lead i=
n program design and this experience also involves navigating extensive cod=
e bases, enhancing my ability to comprehend and contribute to large project=
s. The website is already live, with functionalities receiving acclaims fro=
m our faculties and students. In summer 2024, I worked as a Business Data A=
nalyst intern at SETVI, a SaaS startup, where I greatly improved my communi=
cations and formalized my documentation practices.<br><br>I am passionate a=
bout contributing to OpenAFS through the `netcat for Rx' project, obser=
ving it as a natural extension of my academic and personal interest. I real=
ly look forward to working with the community, learning more about OpenAFS,=
and developing tools for Rx-based services.<br><br>## Availability<br><br>=
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 aro=
und 3 hours and allocate 1 hour daily to exercise. During the weekends, I p=
lan to spend 5 hours on prototyping a startup idea.<br><br>\newpage<br><br>=
# Project Information<br><br>## Netcat for Rx<br><br>OpenAFS uses RxRPC to =
support the distributed files system, which provides reliable ordered messa=
ge delivery, multiplexed channels and built-in security features. However, =
there is no simple command-line utilities for Rx network debugging and inve=
stigation. This project proposes to build a netcat-like tool for Rx protoco=
l. This would fill the gap in the current toolset for OpenAFS administratio=
n and development community.<br><br>For the functionalities of `netcat for =
Rx', we hope to achieve the following objectives:<br><br>=C2=A0- Test R=
x network connectivity (e.g., with echo request)<br>=C2=A0- Debug Rx intera=
ctions<br>=C2=A0- Automate tests particularly for OpenAFS services.<br>=C2=
=A0- Rx server and listener emulation<br><br><br>Considering the massive am=
ount of requests, C program with tight time and space complexity would be d=
esigned for performance. I plan to draw from established netcat sources and=
use cases (like port scanning) and design comparable utility functionaliti=
es. 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.<br><br>## Background Understanding of =
Source<br><br>In an effort to prepare for the development, I performed a re=
view and research on both RxRPC implementation as well as the canonical net=
cat source code. A summary of my understanding is provided below:<br><br>##=
# Understanding RxRPC<br><br>With reference to rxrpc.rst, RxPRC is a reliab=
le two-phase protocol built on UDP. The purpose is to create virtual networ=
k connections such that operational or control data and messages could be s=
ent to the Andrew File System.<br><br>The protocol adopts two-layer design =
using both session layer (for connections) and presentation layer (for conv=
ersion of data format).=C2=A0 The two-phase protocol operation requires cli=
ents sending request blob, server processing requests, server replying, and=
clients receiving a blob of reply.<br><br>The architecture supports multip=
le virtual connections sharing the same transport endpoint, with each conne=
ction identified by 7 parameters (local/remote addresses, ports, direction,=
connection ID, service ID). For reliability, both hard-ACK and soft-ACK ar=
e available.<br><br>For API, we can use AF\_RXRPC with control messages lik=
e RXRPC\_USERCALL\_ID, RXRPC\_ABORT as metadata.<br><br>I also focused on s=
ource code like af\_rxrpc.c and ar-internal.h, and I gained a better idea o=
f internal resource management, structured data handling, protocol mechanic=
s and error handling.<br><br>Such information contributes to my following u=
nderstanding of this project:<br><br>=C2=A0- Map RxRPC=E2=80=99s internal s=
tate management to a simplified interface that can be controlled via comman=
d-line options.<br>=C2=A0- Utilize RxRPC data structures and error-handling=
patterns to ensure that the new RxNetcat tool behaves predictably even und=
er adverse network conditions.<br>=C2=A0- Design test cases that mirror rea=
l-world scenarios in RxRPC communication, thereby reinforcing the tool=E2=
=80=99s reliability and diagnostic value.<br><br><br>### Understanding netc=
at<br><br>Reviewing the netvat.c, I am again amazed by the compact yet vers=
atile commandline utility supporting the operations from both client and se=
rver. Following is some of my observations that I hope to adopt in my futur=
e development:<br><br><br>=C2=A0- Option Parsing and Configuration: process=
ing command-line with standard libraries like getopt.h enables user-friendl=
y and extensible functionality. Therefore, our RxNetcat can have operationa=
l flags for details indictating whether the tool connects to a remote host =
or listens for incoming connections.<br>=C2=A0- Socket Management and I/O M=
ultiplexing: Netcat=E2=80=99s implementation of socket creation, connection=
, and data relay (via loops using select() or poll()) serves as an excellen=
t model for building similar functionality tailored to Rx. This pattern is =
crucial for ensuring that the tool can handle multiple simultaneous I/O ope=
rations, which is particularly relevant given Rx=E2=80=99s multiplexed chan=
nel capabilities.<br>=C2=A0- Error Reporting and Resource Clean-up: The emp=
hasis on graceful error handling and proper resource deallocation in netcat=
=E2=80=99s codebase has informed my approach to developing robust and maint=
ainable code.<br><br><br>### Implications<br><br>By synthesizing these appr=
oaches, the project will:<br><br>=C2=A0- Adapt netcat=E2=80=99s straightfor=
ward, reliable network handling to work with Rx=E2=80=99s unique protocol f=
eatures such as channel multiplexing and built-in security.<br>=C2=A0- Enab=
le diagnostic features like echo requests and connection tracing that refle=
ct both the simplicity of netcat and the complexity of RxRPC.<br>=C2=A0- Pr=
ovide a foundation for automated testing and stress evaluation by mirroring=
netcat=E2=80=99s efficient I/O loop structure in an environment tailored f=
or Rx.<br><br><br>## Project Schedule and Deliverables<br>Following is a te=
ntative plan with a duration of 12 weeks. For each phase, I summarized the =
objectives and the deliverables.<br>### Week 1-2<br>Objectives:<br><br>=C2=
=A0- Conduct research on Rx protocol (and ideally gather user demand for th=
e toolset)<br>=C2=A0- Review netcat functionalities and code bases<br>=C2=
=A0- Finalize the scope of features to be completed in 12 weeks<br><br>Deli=
verables:<br><br>=C2=A0- Scoping document of functionalities<br><br>### Wee=
k 3-6<br>Objectives:<br><br>=C2=A0- Design the tool architecture and develo=
p a command-line interface prototype<br>=C2=A0- Iteratively improve the des=
ign based on the project scale and feedback<br><br>Deliverables:<br><br>=C2=
=A0- A documentation of functionalities with design<br>=C2=A0- Code for pro=
totype<br><br>### Week 7-10<br>Objective:<br><br>=C2=A0- Implement the feat=
ures<br>=C2=A0- Implement ``simple'' unit tests for individual feat=
ures<br><br>Deliverables:<br><br>=C2=A0- Code for implementation<br>=C2=A0-=
Unit test report for features<br><br>### Week 11-12<br>Objectives:<br><br>=
=C2=A0- Finalize the implementation<br>=C2=A0- Conduct thorough testing tha=
t simulates a typical developer workflow<br>=C2=A0- Finalize the documentat=
ion<br>=C2=A0- Prepare for project evaluation<br><br>Deliverables:<br><br>=
=C2=A0- Complete code base<br>=C2=A0- Comprehensive test files streamlining=
use cases<br>=C2=A0- Complete user documentation and maintainer documentat=
ion<br>=C2=A0- Final project report if needed<br><br>## Test Plan<br>For ea=
ch individual functionality, my unit tests will cover:<br><br>=C2=A0- each =
individual modules<br>=C2=A0- command line interface<br>=C2=A0- memory safe=
ty<br><br>For holistic testing, I plan to simulate a typical workflow of a =
developer by:<br><br>=C2=A0- Simulate an OpenAFS environment<br>=C2=A0- Str=
ess testing the tool with high volumes of requests, incomplete requests and=
more to evaluate robustness<br>=C2=A0- Evaluate program performance<br>=C2=
=A0- Verify the accuracy of output presentation<br>=C2=A0- Improve upon fee=
dback=C2=A0 =C2=A0=C2=A0<br></div><div><br></div><br><div class=3D"gmail_qu=
ote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Ma=
r 27, 2025 at 11:55=E2=80=AFAM Zhengfei Li <<a href=3D"mailto:zhengfeili=
.alex@gmail.com">zhengfeili.alex@gmail.com</a>> wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Dear OpenAFS com=
munity and developers,<br><br>I hope this email finds you all well.<br><br>=
My name is Alex (Zhengfei Li), a graduating Computer Science major from Swa=
rthmore College. I am writing to reach out regarding my Google Summer of Co=
de proposal titled "Netcat for Rx".<br><br>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 woul=
d greatly appreciate any feedback or guidance on the status of this project=
and my proposal. Specifically, I am eager to understand:<br>- unique aspec=
ts of Rx that demand special attention<br>- suggestions on the tool's s=
cope<br>- any potential pitfalls I should be aware of<br><br>Thank you very=
much for your time reviewing my proposal. I am open to any feedback, engag=
ing with you, and refining my proposal with your expertise.<br><br>Best,<br=
>Alex<br><br><--- Below is the plain text of my proposal ---><br># Bi=
ography<br><br>Greetings! I'm Alex, a graduating Computer Science major=
from Swarthmore College, passionate about file systems and networks projec=
ts.<br>This fall, I will be joining the Carnegie Mellon University MSCS pro=
gram, eager to explore deeper into networking.<br><br>I have completed cour=
ses in OS and Computer Networks, gaining a robust understanding of file sys=
tems, TCP/UDP, and socket programming with C and Python. In my "Simple=
Firewall" course project, I extensively used netcat for tasks like de=
bugging with manual protocol interactions and setting up simple servers or =
listeners to test firewall rules. This experience greatly improved my under=
standing of network security and my skills in network analysis and troubles=
hooting.<br><br>Familiarizing myself with the Rx protocol, I achieved a pri=
mary understanding that Rx is a connection-oriented protocol that operates =
over UDP and supports service multiplexing. I explored tools like `rxgen=
9; and `rxdebug', though I have not yet used it productively. I am a qu=
ick learner and I am confident that I can convert my theoretical knowledge =
into implementation practices in days.<br><br>I have work experience relate=
d to software. During the summer of 2023, I joined a Computer Education res=
earch team and collaborated on developing an interactive online exercise we=
bpage based on an open-source project Runestone. I took a lead in program d=
esign and this experience also involves navigating extensive code bases, en=
hancing my ability to comprehend and contribute to large projects. The webs=
ite is already live, with functionalities receiving acclaim from our facult=
ies and students. In the summer of 2024, I worked as a Business Data Analys=
t intern at SETVI, a SaaS startup, where I greatly improved my communicatio=
ns and formalized my documentation practices.<br><br>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 lo=
ok forward to working with the community, learning more about OpenAFS, and =
developing tools for Rx-based services.<br><br>## Availability<br><br>I pla=
n to start this 12-week project on June 16, with a commitment of around 8 h=
ours 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 t=
o spend 5 hours on prototyping a startup idea.<br><br># Project Information=
<br><br>## Netcat for Rx<br><br>OpenAFS uses RxRPC to support the distribut=
ed files system, which provides reliable ordered message delivery, multiple=
xed channels and built-in security features. However, there are no simple c=
ommand-line utilities for Rx network debugging and investigation. This proj=
ect proposes to build a netcat-like tool for Rx protocol. This would fill t=
he gap in the current toolset for OpenAFS administration and development co=
mmunity.<br><br>For the functionalities of `netcat for Rx', we hope to =
achieve the following objectives:<br>=C2=A0 =C2=A0 -Test Rx network connect=
ivity (e.g., with echo request)<br>=C2=A0 =C2=A0 -Debug Rx interactions<br>=
=C2=A0 =C2=A0 -Automate tests particularly for OpenAFS services.<br>=C2=A0 =
=C2=A0 -Rx server and listener emulation<br><br>Considering the massive amo=
unt of requests, C programs with tight time and space complexity would be d=
esigned for performance. I plan to draw from established netcat sources and=
use cases (like port scanning) and design comparable utility functionaliti=
es. In addition, I would also investigate unique features of Rx (like chann=
el multiplexing) and devise helpful tools with reference to developers'=
daily experiences and demands.<br><br>## Project Schedule and Deliverables=
<br><br>Following is a tentative plan with a duration of 12 weeks. For each=
phase, I summarized the objectives and the deliverables.<br><br>### Week 1=
-2<br><br>Objectives:<br>=C2=A0 =C2=A0 -Conduct research on Rx protocol (an=
d ideally gather user demand for the toolset)<br>=C2=A0 =C2=A0 -Review netc=
at functionalities and code bases<br>=C2=A0 =C2=A0 -Finalize the scope of f=
eatures to be completed in 12 weeks<br><br>Deliverables:<br>=C2=A0 =C2=A0 -=
Scoping document of functionalities<br><br>### Week 3-6<br><br>Objectives:<=
br>=C2=A0 =C2=A0 -Design the tool architecture and develop a command-line i=
nterface prototype<br>=C2=A0 =C2=A0 -Iteratively improve the design based o=
n the project scale and feedback<br><br>Deliverables:<br>=C2=A0 =C2=A0 -A d=
ocumentation of functionalities with design<br>=C2=A0 =C2=A0 -Code for prot=
otype<br><br>### Week 7-10<br><br>Objective:<br>=C2=A0 =C2=A0 -Implement th=
e features<br>=C2=A0 =C2=A0 -Implement ``simple'' unit tests for in=
dividual features<br><br>Deliverables:<br>=C2=A0 =C2=A0 -Code for implement=
ation<br>=C2=A0 =C2=A0 -Unit test report for features<br><br>### Week 11-12=
<br><br>Objectives:<br>=C2=A0 =C2=A0 -Finalize the implementation<br>=C2=A0=
=C2=A0 -Conduct thorough testing that simulates a typical developer workfl=
ow<br>=C2=A0 =C2=A0 -Finalize the documentation<br>=C2=A0 =C2=A0 -Prepare f=
or project evaluation<br><br>Deliverables:<br>=C2=A0 =C2=A0 -Complete code =
base<br>=C2=A0 =C2=A0 -Comprehensive test files streamlining use cases<br>=
=C2=A0 =C2=A0 -Complete user documentation and maintainer documentation<br>=
=C2=A0 =C2=A0 -Final project report if needed<br><br>## Test Plan<br><br>Fo=
r each individual functionality, my unit tests will cover:<br>=C2=A0 =C2=A0=
-each individual modules<br>=C2=A0 =C2=A0 -command line interface<br>=C2=
=A0 =C2=A0 -memory safety<br><br>For holistic testing, I plan to simulate a=
typical workflow of a developer by:<br>=C2=A0 =C2=A0 -Simulate an OpenAFS =
environment<br>=C2=A0 =C2=A0 -Stress testing the tool with high volumes of =
requests, incomplete requests and more to evaluate robustness<br>=C2=A0 =C2=
=A0 -Evaluate program performance<br>=C2=A0 =C2=A0 -Verify the accuracy of =
output presentation<br>=C2=A0 =C2=A0 -Improve upon feedback=C2=A0 =C2=A0=C2=
=A0</div>
</blockquote></div></div>
--000000000000f8008a0631f86f77--