Description

Develop a networked application using TCP sockets

Implement a protocol according to a given specification from both the client and server side

Implement client-side checking to ensure only valid messages are sent to the server

Introduction

Note: This assignment is based on the challenge presented at https://berthub.eu/articles/posts/part-2-reverse-engineering-source-codeof-the-biontech-pfizer-vaccine/. This is a real-world problem, giving you the potential to truly contribute to vaccine research.

In this assignment, you will be converting input virus RNA to an optimised form that is likely to create a better vaccine. Your task is to use TCP sockets to create a client process that sends unoptimised RNA to a server, which replies with optimised RNA. The protocol that your solution must implement is described below.

Background Information

It is strongly recommended you read Bert Hubert’s post Reverse Engineering the source code of the BioNTech/Pfizer SARS-CoV-2 Vaccine for relevant background information.

The basic idea is that vaccines can be developed by slightly modifying some RNA from a virus. Nature groups three nucleotides into a codon which can be represented as a group of three G, C, A, or T characters. Thus, there are 64=4³ possible codons. Each codon is converted into an amino acid when processed by a cell to fold into a protein. But there are only 20 different amino acids. This means a given amino acid may be able to be encoded by multiple different codons.

For this assignment, you must implement a set of optimisation rules that take a string of RNA as input and return an optimised version.

Optimisation Rules

To determine your optimisation rules, you can use details of how RNA from the COVID-19 virus S protein has been modified to create the extremely efficient BioNTech/Pfizer SARS-CoV-2 Vaccine S protein.

It is not acceptable to simply return the input RNA as the output. Your rules must make some attempt to optimise the input while ensuring that the associated amino acids for each codon are identical in the output. For this purpose, you are provided with codonaminoacid.csv which specifies the amino acid associated with each codon.

As a starting point, it is generally the case that a higher number of G and/or C characters improves the efficiency of an mRNA vaccine. So one approach would be to consider the amino acid generated by a given codon and replace it with the codon with the most G and/or C characters that produces the same amino acid. Please do not feel that you must limit your approach to this guideline.

Protocol

Each message in the protocol consists of a string of ASCII characters followed by the line feed character (ASCII code 10). All messages from the client should be case insensitive. All messages from the server should be uppercase.

An interaction begins with the client sending a START RNA message to the server.

The client then sends a message consisting of G, C, A, and/or T characters to represent codons.

The server then responds with a message consisting of G, C, A, and/or T characters to represent optimised codons.

The client can then either send a new START RNA message (in which case the process repeats) or send a DISCONNECT message.

Once the client has sent a DISCONNECT message, it should exit. Once the server has recieved a DISCONNECT message, it should close the socket and wait for a new connection.

Any other message sent to or from the client is considered an error, and should result in the receiving party dropping the connection. In particular, any RNA string that includes characters outside of G, C, A, or T, or has a length that is not a multiple of three, must be considered an error.

Interface

Your client must be able to be invoked by taking either two or three command line arguments. The first argument is the host name of the server to connect to. The second argument is the port number of the server to connect to. The third, optional, argument is a filename.

If the filename is specified, your client must read the contents of the first line of the file and determine if it is a valid RNA string. If it is not valid, the client should display an appropriate error message and exit. If it is valid, your client must send a START RNA message to the server, followed by the RNA string from the file. The client must then print out the response from the server before sending a DISCONNECT message and exiting.

If no filename is specified, the client should present a menu to the user, allowing them to either send RNA, or to exit.

In the case the user chooses to send RNA, your client must prompt the user to type it in. If the resulting input is not valid, the client should display an appropriate error message. If the input is valid, the client should send this to the server (after a START RNA message) and output the response for the user. In either case, your program must then display the menu again to allow the user to make a new choice.

In the case the user chooses to exit, the client should send a DISCONNECT message to the server if it has sent at least one START RNA message in the session. The client should then exit.

Example

These examples show the protocol only. This is not how interactions with the program should look to the end user (see the Interface section above for these details). Note, also, that the protocol does not include the “Client: ” or “Server: ” strings – they are just included to make these examples clearer.

Example 1

Client: DISCONNECT

Note that the server drops the connection after an error.

Example 2

Client: START RNA

Client: atg Server: AUG

Note that the client drops the connection after an error.

Example 3

Client: START RNA

Client: ATGTTT

Server: ATGTTC Client: ATGTTT

Note that the server drops the connection after an error.

Example 4

p

Client: START RNA Client: ATGTT

Note that the server drops the connection after an error.

Example 5

Client: START RNA Client: ATGTTT

Server: ATGTTC

Client: DISCONNECT

Both client and server complete normally.

Example 6

Client: START RNA

Client: ATGTTT

Server: ATGTTC

Client: START RNA

Client: TTTATG

Server: TTCATG

Client: DISCONNECT

Both client and server complete normally.

Details

You may use any programming language and libaraies that run on turing.une.edu.au to implement your solution. Your solution should be submitted through Moodle in a single .zip or .tgz file which, along with your source code and any instructions to compile your code, should also include a file named rules.pdf that describes the optimisation rules you have implemented, and the following two shell scripts:

1. sh which takes a port number as its only command-line parameter and attempts to start a server on that port. If the server is unable to be started (perhaps because that port is already in use), your program should exit with an appropriate error message.
2. sh which takes a host name as its first command-line parameter, a port number as its second command-line parameter and a filename as its optional third command-line parameter and attempts to connect to the server with the given host name and port number. If the client is unable to connect, it should exit with an appropriate error message. The client should then behave as specified in the Interface section above, depending on whether a filename was included in the command-line arguments

For COSC340 students, it is enough to support a single client at a time (i.e. once a client disconnects, the server should wait for a new client to connect). COSC540 students are required to support multiple concurrent clients (i.e. there should be no need for one client to finish before a new client connects). In either case, the server process should continue executing until explicitly killed by the operating system (e.g. via an exit signal when the user presses Ctrl+c).

Note that program specifications are not always clear. If you are uncertain about any aspect, you are typically better off asking than making assumptions. Please use the appropriate discussion forum to ask for clarification, if required.