My application for all the world to see

[kingoftheconnors]

The GSoC page suggested putting my application as an issue. I think this is what's expected. So, tada! .. .. .. Connor-McPherson Connor-McPherson@mocs.utc.edu sites.google.com/mocs.utc.edu/mcpherson-portfolio

Improve Mio Support on Windows When I first started high school, I was handed an old C++ project my older brother made as a windows multiplayer game made to span a LAN network. Back then we weren’t involved in the open-source community, so we just pulled down the closest socket library we could find.

We used the winsock library, and yes, it’s disgusting. Here’s a snippet:

 // Create the socket
 SocketFD = socket(PF_INET, SOCK_DGRAM, 0);
 // Fill in my address data
 MyAddr.sin_family = AF_INET;
 MyAddr.sin_port = htons(27000);
 MyAddr.sin_addr.s_addr = INADDR_ANY;
 memset(MyAddr.sin_zero, '\0',sizeof(MyAddr.sin_zero));
 setsockopt(SocketFD, SOL_SOCKET, SO_REUSEADDR, &optionValue, sizeof(optionValue));
 // Bind the socket to the host at the proper port
 bind(SocketFD,(struct sockaddr*)&MyAddr,sizeof(MyAddr));
 // Fill in the peer's address data
 //MyAddr.sin_addr.s_addr = inet_addr("192.168.0.255"); // Broadcasting (Upstairs Network)
 MyAddr.sin_addr.s_addr = inet_addr(FinIP); // Broadcasting (Upstairs Network)
 memset(MyAddr.sin_zero, '\0',sizeof(MyAddr.sin_zero));
 socklen_t StAddrSize = sizeof(struct sockaddr_storage);
 // Make socket nonblocking
 u_long One=1;
 ioctlsocket(SocketFD,FIONBIO,&One);
 // Make the socket capable of broadcasting
 char Broadcast = 1;
 int RV = 0;
 RV = setsockopt(SocketFD, SOL_SOCKET, SO_BROADCAST, &Broadcast, sizeof(Broadcast));
 if( RV < 0)
   printf("Error with Broadcasting Setting.\n");

Ever since last year, I’ve been rethinking how the game communicates and I’ve been looking for a robust communication package. This requires a complete refactoring of the I/O and how the network inputs are set up.

Mio is undergoing a similar change: refactoring its I/O Windows implementation. It will be an involved project to rebuild the wepoll interface in rust. I have first-hand experience with the worst a windows socket system can look like, and I have been introduced to other libraries such as MPI through research at the University of Tennessee at Chattanooga. Although I am still a greenhorn when it comes to rust, I believe my experience with the Windows operating system and networking can help in refactoring the Mio implementation of its I/O.

Schedule of Deliverables The first milestone will be to set up the environment first. This is because, as shown in test-first development, you can improve your overall efficiency if you verify that tests fail first to prove that it works when it passes. This first milestone would be to add unit tests for I/O. These will initially work because of Mio’s already existing (but not ideal) I/O implementation. Mio already has a testing framework set up using Cirrus CI, making this first deliverable extremely easy. Many of the unit tests may already exist.

The second deliverable will be the rust parallel to wepoll’s epoll_create, epoll_ctl and epoll_close. Functionality of these epoll instances will then be added throughout the first month. Ideally, epoll would be able to receive information from sockets and ports by the end of the first month, even if the order of receiving is not managed concurrently.

The second month would deal with using Rust and Tokio’s concurrency software to optimize the epoll system, as well as adding additional I/O functionality, such as the variety of uses associated with epoll_wait. Open Source Development Experience Though I am ashamed to say, I have not yet taken part in the open-source community, as much as I wish I had. Most of my work has been to add to the MocsArcade code base, a project based at my university to make a library of student-made games. This repository can be found on github (github.com/mocsarcade). Beyond that, the rest of my free time is invested in the private repo my older brother left me, the one written in C++ using winsock. Academic Experience I am majoring in Computer Science and currently studying COBOL, Perl, software engineering practices and Numerical Analysis. I am double-minoring in writing and math. I believe the duality of science and humanities helps me gain a more well-rounded education and gives me a more diverse set of skills. In my freshman year, one of my professors taught me that the purpose of the computer science degree is to teach students how to learn, not how to do everything in computer science. He encouraged me to teach myself beyond what I’m told in class. Even when I graduate in a year and a half, I plan to continue learning throughout my entire life, and through that gain a fuller understanding of the field of computer science as a whole. I desperately wish to learn rust and I am well versed in DevOps. Even if I’m not accepted into a GSoC internship, I plan to take part in the open-source community with what free time I carve out for myself. My goal is to learn through making. Why Me I believe my experience with networking, although still small, can add to the project by helping to build the system with concurrency in mind. My experience with sockets and MPI together can help me better understand Tokio and Mio as the project advances.

Still, I would recommend at least one other student that is more familiar with Rust. I know I’m not making a great case for myself, but I am neither familiar nor confident when it comes to Rust. I have experience in Python, Java, C++, COBOL and PhP, and I believe I will be able to pick up Rust quickly, but the hands-on activities needed for this project will require a deeper understanding of Rust than I currently have. I’m afraid the unique aspects of concurrency in Rust are still new to me… for now! In Conclusion I am not a professional at Rust, nor do I pretend to be. I plan to become one over the space of this summer, while being able to improve Mio as I improve. I believe my interest and experiences in I/O networking will be able add to Mio and improve its current implementation.

[carllerche]

Great start!

To make the application more complete, I think the following two sections could help a lot:

• A high level analysis of how wepoll is implemented. Imagine you are writing "overview" documentation and are trying to give the reader enough context to be able to dive into the wepoll source.
• A description of how the ideas implemented in wepoll would apply to mio. Mio is trying to do something (similar but) different than wepoll. wepoll aims to provide API compatibility with epoll. Mio, on the other hand, provides its own set of APIs that work in isolation (Poll, TcpStream). This will make implementing the wepoll strategy in mio easier.
• As a follow up point, wepoll is not able to support edge-triggered notifications. Mio will be able to. Could you describe how that might work? Hint: it will require hooking into TcpStream::ready and TcpStream::write, which mio can do because it provides its own types and read / write function implementations.

After adding these sections, I would suggest submitting the proposal via the google summer of code UI.

Cheers!