Chapel Lang - 2021 - Lakshya Singh
Chapel Lang - 2021 - Lakshya Singh
Socket Library
Google Summer of Code 2021
Introduction
★ Algorithms
★ Data Structures
★ Object-Oriented Programming
I have similar aspirations from Google Summer of Code. I want to work more in an
open-source community where we have several people from different parts of the
world working as a team and building projects collaboratively. And what better than
Google Summer of Code, which will also allow me to hone my skills and acquire new
ones under quality mentoring organisations and best mentors’ guidance.
The project has great mentors who are always willing to provide the best possible aid
and are very responsive, friendly and ready to share their knowledge. This has been a
fantastic experience for me. It allows me to interact with mentors and other
contributors and gain more knowledge while staying connected with the
community and contributing more to the project through discussion and code.
Coding Experience
I am also familiar with Python Programming and Scripting. I have used Python for
Machine Learning Model Development, setting up Backend Server using Django and
DjangoREST and small scripting purposes.
I started coding in the chapel at the start of February. And followed the getting
started pages :
● I started with Learning Chapel Page and went over to the youtube Talk by
Brad Chamberlain to get insights into Chapel’s principles and working.
● I went through the Learn X in Y minutesdocs for Chapel and fiddled around
with the code in it.
● I have gone through the Primers as my initial introduction to distributed and
parallel programming into the chapel world.
● I made several pull requests to the Chapel Project and also found some issues
while working on it.
● I worked with a few modules of Chapel like Path, DateTime, Heap, IO and
Sort.
I have implemented several HTTP Server primarily for use as REST and GraphQL APIs
from the ground up using vanilla NodeJS and Python and worked with higher-level
APIs of frameworks like Django and Express. While implementing these projects, I
have gained insights into working with Web Services like web sockets and internet
protocols necessary for the project.
As I am also a part of the CyberSec Group of IIT BHU, I have participated in several
CTFs where we band together to hack our way through the challenges thrown at us.
This has provided me insights into web security, and we as a team used to develop
over partial work done by others and develop upon it.
This was the first time I was working with React, and I wasn’t familiar with any of the
concepts like JSX, hooks, CSS modules etc., that were used in it. As the project was in
the release phase, I had to keep my learning and work going side by side. I went
through the docs for React, React Hooks and NextJS. I tried to level up my
knowledge to get insights into their work and hence can optimise them.
Apart from this, I also try to contribute to open-source tools that I use by discussing
or creating issues wherever necessary after triaging.
Issues
Prerequisites
The key elements that will be of significant concern during the project include:-
Description
Sockets are an abstraction over Pipes that allow communication between processes
even if they aren’t running on the same system, unlike Pipes. The most widely used
Sockets are BSD sockets which are also known as Unix Sockets more commonly.
Socket Module involves making system calls to the kernel through the program,
which allows us to work with sockets at the network level.
There are two types of sockets Client and Server both require several steps in
creating a connection as listed below :
● Create Socket -
Returns a file descriptor for
communication.
● Connect - Client
Socket makes connection
requests to server socket by
specifying its Unique
Address.
Note: I have written all the code snippets provided in the document below.
The socket module will consist of a socket record with methods for initialising the
socket and getting a file object from the file descriptor returned by calling the C
socket function; bind, listen and accept will work as stated above. In contrast, read
and write will work using Chapel IO.
While the GNU C Socket Module provides the ability to interact with sockets, calls
made by it are blocking and single-threaded. Some of the procedure calls that need
to be customised for Chapel include :
1. Accept
2. Receive
3. Connect
4. Write
The Socket Module for Chapel needs to be made to ensure all procedures are
non-blocking and can use multiple threads for task distribution. Design decision
need to be made about how will parallelism and concurrency be secured with the
sockets, some of the methods that I will explore:
● Using Select’s
multiplexing
capabilities to work
with making receive
calls non-blocking and
dealing with erroneous
sockets. Select allows
the program to sleep
until one or more file
descriptors are ready
for IO.
● We will look further into ioctl to mark sockets as non-blocking and deal with
associated errors that the program will generate.
Utilising Chapel IO
Chapel’s IO module has support for working with file descriptors using openfd and
openfp. Instead of working with C’s read/recv and write functions, we can interpolate
Chapel’s IO module to work seamlessly with socket file descriptors providing
first-hand support for parallelism. Chapel IO will also work in accepting sockets from
socket.accept, which can then use regular IO Channels for reading and writing.
The file object returned will be stored inside the class, encapsulating it from users. It
will provide access to read and write operation on socket file descriptors after the
connection is established for TCP Sockets, whereas for UDP functions similar to C’s
sendTo and readFrom need to be implemented using Chapel’s IO.
Also, currently, the Chapel IO makes blocking reads and writes. The project duration
will involve making it work in a non-blocking manner. This will require setting up
communication between the running process and read/write a procedure that will
convey that the read/write operation requested by the file object is completed and
any further task related to it can proceed now. I will explore possible methods in the
run of the project to make the procedures non-blocking.
The need to implement many of the enums and structures will not be required as
we can import them from the Sys package directly. The functions over there are a
direct port of C functions. Therefore, they will be needed to be changed for
non-blocking versions while some procedures can be directly used, like :
● sys_close
● sys_fcntl
● sys_bind
● sys_select
Utility Functions
The module will include socket creation and communication functions and have
utility structures abstracted for chapel’s need to make it easy for users to create Web
Services while working with the socket module. Some of the procedures are :
● gethostname method to retrieve a list of IP addresses from the domain
name.
● Procedure for converting ip_address in string form and port in integer form to
standardised byte forms
● Inverse Procedures for converting from byte forms of port and IP Address to
readable forms
● getprotocol for converting strings to protocol enum values
We can build the module by taking Design Decisions from Python’s Socket Module
while extending C Socket Module’s capabilities as per design decisions. Unlike C’s
functional format of Socket Module, we would like to make the procedures in an
Object-Oriented architecture instead, allowing for encapsulation of several features
and hiding implementation details from users, only making higher-level APIs
available to them.
The Network Server will be implemented as a part of the HTTP/server module. The
classes listed are intended to simplify the task of writing servers based on commonly
used Protocols. The basic idea for them is to inherit from a parent BaseServer class
and build upon them as per the need for protocol.
We will create a
BaseRequestHandler class
which the user will pass on to
the server class.
BaseRequestHandler will
contain a handle() method that
the user will be required to
override, or else a primary
handler will be implemented.
We will create server classes ( listed below ) which will be instantiated by passing the
BaseRequestHandler class instance and server address, i.e. IP and Port :
● TCP Server: This will use the TCP Protocol for providing continuous
connection and data streaming capabilities between client and server. The
user will be required to give the handler and address needed to connect and
parameters for binding or to communicate so that client and server can be
distinguished.
● UDP Server: This uses datagrams, which are discrete packets of information
that may arrive out of order or be lost while in transit. The parameters are the
same as for TCP Server.
Base Server Class
The base server class will have the following methods attached to it, which will create
and start the server :
● init procedure will handle the creation, binding of the socket and begin
listening based on the provided arguments for IP and Port.
● handleRequest method will deal with a single request by opening the client
socket for reading and writing. It will check whether the client is readable or
the timeout hasn’t occurred, after which it calls processRequest while
handling any errors
● startServer handles any new request using processRequest. It will observe
for shutdown using a shared atomic variable till then it will keep on listening
for new request
● processRequest method will create a new task for accepted connection by
creating a new object BaseRequestHandler provided during instantiation and
add the task into a list of tasks
● handleError will provide basic error handling and can be overridden by the
user
● stopServer will set the atomic Variable and then starts reaping/joining all the
ongoing tasks.
HTTP Server
Hypertext Transfer Protocol ( HTTP ) uses TCP as a network transport layer. An HTTP
Communication differs from regular TCP communication as the data being
transferred between clients and server includes several details about itself, its host,
the protocol used etc. Parts of an HTTP Response are :
● Headers
● Body
● Response Status Code
● Method
The HTTP Server will be required to parse this information associated with the
request into different records. Based on the type of request, the user will be required
to provide a Base Handler to deal with the request.
HTTP Support several methods, some of the widely used ones are as below :
1. GET: The GET method requests a representation of the specified resource.
Requests using GET should only retrieve data
2. POST - The POST method is used to submit an entity to the selected resource.
4. PUT - The PUT method replaces all current representations of the target
resource with the request payload.
The HTTP class’s parseRequest function will utilise regex expressions to extract out
the components and verify the header. The implementation of parseRequest and
associated record will look as follows :
We can build the HTTP Server upon the TCP Server Class of the Network Servers
designed above for Chapel.
The examples built in the community will be taken as a starting point as some of the
projects have been worked upon a lot and can help speed up the process. One of
them is a C multithreaded server pico, and I also found that a complete HTTP
module is implemented in chapel-http.
The HTTP server’s demonstration will include the initial task of handling GET Method
requests while developing upon the GET Method handler’s principles and extending
it to other methods in later phases of the module.
HTTP/1.1 includes a keep-alive mechanism that allows for multiple requests through
the same connection. Otherwise, the connection is closed after a single
request-response cycle between client and server.
It’s up to the server whether it accepts the keep-alive connection or not. We can
choose to implement the functionality for persistent connections at the end of the
project given time availability so that the server can support HTTP/1.1 completely.
The request parsing will involve checking for properties like timeout and max
request-response cycle before closing the connection. We can have defaults for both
values to deal with idle connections and ensure that CPU time is not wasted
checking those connections.
Base HTTP Module Implementation
Why is this task exciting to you? Why did you choose
this particular task? What do you hope to learn by
working on it?
I have been working in the field of Web Development for over a year now. I have also
worked on web security which is of significant concern in today's world. This
particular task excites me because it will allow me to work with the lower-level APIs
of Web Technology, which I have always wanted, instead of just working with Higher
Level Abstractions. This task will help me get insights to answer better the question
How the Web works?
I have chosen this particular project because I have always looked around for a while
working with Web Technologies is Better Performance. I have moved from Django
to NodeJS from ReactJS to VueJS in search of performance, which Chapel provides at
first hand and is one of the core fundamentals of the language. This seems to be a
longstanding wishlist from Chapel Community and will be a leap for Chapel’s usage
in the community.
The task will provide me with a deeper understanding of the working of Web
Services and associated Protocols. It will also allow me to understand better the
development and architecture of other famous Backend Frameworks like Django,
Express, etc. By the end of this project, I would have gained a better knowledge of
socket programming and HTTP services and details about their internal moving
parts. As a student, this project will allow me to interact with knowledgeable and
experienced mentors. I will get to know about developing libraries from the ground
up and working on large open-source projects.
Provide a rough estimated timeline for your work on the
task. This timeline should take into account any
non-coding time, such as exams, GSoC midterms, and
vacation. Describe milestones you expect to achieve as
you work towards the task.
April 14, 2021 - May 17, 2021 ➢ Work on issues : #16394, #8758,
#17439, #7662 and merge pending PRs
➢ Triage possibility of optimisation in
Heap Module for merging list
➢ Work on timezone class
implementation for DateTime module
➢ Learn more about non-blocking IO
and C networking.
➢ Stay connected with the community
and learn chapel
May 17, 2021 - May 30, 2021 ➢ Learn more about Data Parallelism
and Task Parallelism
➢ Discuss Approaches to integrate
parallelism in Socket and HTTP
Module
➢ Read through IO, C Interoperability,
Sys Module
June 7, 2021 - June 21, 2021 ➢ Finalise the design decisions for the
socket module
➢ Start integrating C functions into
socket module to ensure non-blocking
nature
➢ Develop necessary sub-records for
essential socket interaction
➢ Add test and example for essential
socket functions
June 22, 2021 - June 27, 2021 ➢ Update procedures for parallelism
➢ Bug fixes and refactors module
architecture for optimisation
➢ Add more tests as needed
June 28, 2021 - July 7, 2021 ➢ Add utility functions for Socket
Module
➢ Add tests for updated server functions
July 8, 2021 - July 11, 2021 ➢ Discuss design for the network server
and its final implementation
➢ Add classes for Network Servers
July 19, 2021 - July 22, 2021 ➢ Add new test cases for Network Server
Classes.
➢ Bug fixes and refactoring code for the
network server module
➢ Design Decision for HTTP module
prepare pseudo-codes
July 22, 2021 - August 5, 2021 ➢ Start implementing the HTTP module
➢ implement abstract and base classes
for HTTP module
➢ Add new test and examples for the
HTTP module
August 12, 2021 - August 15, 2021 ➢ Discuss with the community about
next steps
➢ Get ideas about current
implementation and chance for
improvements
➢ Decide next milestones for module
References
● https://summerofcode.withgoogle.com/how-it-works/
● https://www.man7.org/linux/man-pages/man7/socket.7.html
● https://linux.die.net/man/3/send
● https://docs.python.org/3/howto/sockets.html
● https://dzone.com/articles/parallel-tcpip-socket-server-with-multi-threading
● https://www.educative.io/edpresso/how-to-implement-tcp-sockets-in-c
● https://www.gnu.org/software/libc/manual/html_node/Sockets.html
● http://www.dcs.gla.ac.uk/~johnson/teaching/CS-1Q/slides/lecture4/net.pdf
● https://chapel-lang.org/gsoc/ideas.html#sockets-library
● https://www.binarytides.com/socket-programming-c-linux-tutorial/
● https://realpython.com/python-sockets/
● https://docs.python.org/3/library/http.server.html
● https://docs.python.org/3/library/socketserver.html
● https://gist.github.com/laobubu/d6d0e9beb934b60b2e552c2d03e1409e
● https://github.com/marcoscleison/chapel-http