We embark on the fifth challenge! If you’d like to jump straight to my solution, here is the GitHub link.

Problem Requirements:

1. Build a TCP proxy server that intercepts connections.

2. Accept connections from clients, and establish connections with the budget-chat server hosted at chat.protohackers.com on port 16963. Assume that routing of clients to your proxy server instead of the budget-chat server has been taken care of already.

3. Forward messages sent back and forth between the budget-chat server and the clients, while replacing Boguscoin addresses with Tony’s address, 7YWHMfk9JZe0LM0g1ZauHuiSxhI.

4. A substring is considered to be a Boguscoin address if it satisfies all of:

   1. it starts with a "7"

   2. it consists of at least 26, and at most 35, alphanumeric characters

   3. it starts at the start of a chat message, or is preceded by a space

   4. it ends at the end of a chat message, or is followed by a space

Solution:

As usual, we start by writing code to accept multiple simultaneous TCP connections.

We need to implement the “handleClient” function. I saw the use of the sync.Once primitive in some other solutions, so I incorporated it into my own.

Lets look at the “forward” function, which is responsible for forwarding messages back and forth between the client and the budget-chat server, while also searching for Boguscoin addresses.

All that’s left, is to implement a function that parses each message, searching and replacing valid Boguscoin addresses with Tony’s address.

On to the next one.

Subscribe now

This next challenge offers a brief respite. While not too difficult, we need to be familiar with the UDP protocol.

If you’d like to jump straight to my implementation, here’s the GitHub link.

Problem Requirements:

1. Build a server that accepts UDP packets.

2. Users can insert key value pairs, update values for existing keys or retrieve the value for a particular key.

3. Insert/Update Requests:

   1. When a user wishes to insert a key value pair, or update the value of an existing key, he sends a string consisting of the key and value, separated by a ‘=’ symbol.

   2. Some rules associated with keys:

      1. Keys cannot contain the ‘=’ sign.

      2. Other than the equals sign, keys can be made up of any arbitrary characters.

      3. The empty string is a valid key.

   3. Some rules associated with values:

      1. The value can be any arbitrary data, including the empty string.

      2. Values can contain the ‘=’ sign.

   4. An insert request does not yield a response.

4. Retrieve Requests:

   1. A request that does not contain an equals sign is a retrieve request.

   2. In response to a retrieve request, the server must send back the key and its corresponding value, separated by an equals sign.

   3. If a requests is for a key that has been inserted multiple times, the server must return the most recent value.

   4. If a request attempts to retrieve a key for which no value exists, the server can either return a response as if the key had the empty value (e.g. "key="), or return no response at all.

5. The server must implement the special key "version".

   1. This should identify the server software in some way.

   2. Corresponding value cannot be an empty string.

   3. Attempts by clients to modify the version must be ignored.

Solution:

Lets start by defining the Database struct.

We need to write code that allows the database to handle UDP packets.

What’s left is to implement the “handleInsertRequest” and “handleRetrieveRequest” functions.

Another day, another W.

Subscribe now

The third challenge awaits! If you want to jump to my implementation directly, here’s the GitHub link.

Problem Requirements:

1. Build a TCP server that can handle at least 10 simultaneous clients.

2. When a user sends a connection request, respond with a custom welcome message.

   Example : Welcome to budget-chat! what do we call you?

3. The user responds to the welcome message with a name, which must be valid.

   A valid name must:

   1. contain at least 1 character.

   2. consist entirely of alphanumeric characters (uppercase, lowercase, and digits).

   Note that:

   1. The server may or may not allow users to pick duplicate names (my solution does not).

   2. A user is said to have “joined” the chat room after he has selected a valid name.

4. Once a new user joins, notify all other online users. Send a list of online users to the newly joined user.

5. Messages sent by a user must be broadcasted to all other users.

6. When a user leaves the chat room, notify all other online users.

7. Refer to the problem link for message formats.

Solution:

Let’s start by defining the BudgetChat struct.

Now lets accept multiple client connections simultaneously.

Before we implement the “handleClient” function for BudgetChat, lets define some constants for the message formats.

Now, lets define the “handleClient” function:

There’s a bunch of functionality to implement, lets start with setting the user’s name, provided its valid.

Now we define 2 helper functions, broadcastData (broadcasts bytes to all clients except the source of the data) and sendData(sends data to a specific client only).

We use these 2 helper functions extensively to do the following:

1. Broadcast messages sent by a user:

   

2. Broadcast a notification to other users informing them that a new user has joined the chat room, and send a list of online users to the newly joined user:

   

3. Broadcast a message to other online users when a user leaves the chat room.

   

The monster falters and falls, its reign has ended. For now, victory is ours!

Subscribe now

With the first challenge behind us, the second one looms ahead, more difficult, but not beyond reach. En garde!

If you’d like to jump straight to my implementation, here’s the GitHub link.

Problem Requirements:

1. Build a server that accept TCP connections from multiple clients simultaneously.

2. Each client wishes to keep track of the price of its asset at different timestamps.

3. To keep bandwidth usage down, a simple binary format has been specified for requests. Each request will be 9 bytes long, and will not be separated by any delimiters.

   The general format of a request:

   

   The first byte of a message is a character indicating its type. This will be an ASCII uppercase 'I' or 'Q' character, indicating whether the message inserts or queries prices, respectively.

   The next 8 bytes are two signed two's complement 32-bit integers in network byte order (big endian), whose meaning depends on the message type.

4. The client can send 2 types of requests:

   1. Insert Request:

      An insert request lets the client insert a timestamped price.

      

      • The first int32 is the timestamp, in seconds since 00:00, 1st Jan 1970.

      • The second int32 is the price, in pennies, of this client's asset, at the given timestamp.

      Note that:

      • Insertions may occur out-of-order.

      • While rare, prices can go negative.

      • Behaviour is undefined if there are multiple prices with the same timestamp from the same client.

   2. Query Request:

      A query request lets the client query the average price over a given time period.

      

      • The first int32 is mintime, the earliest timestamp of the period.

      • The second int32 is maxtime, the latest timestamp of the period.

      • The server must compute the mean of the inserted prices with timestamps T, mintime <= T <= maxtime.

      • If the mean is not an integer, it is acceptable to round either up or down, at the server's discretion.

      • The server must then send the mean to the client as a single int32.

      • If there are no samples within the requested period, or if mintime comes after maxtime, the value returned must be 0.

5. Where a client triggers undefined behaviour, the server can do anything it likes for that client, but must not adversely affect other clients that did not trigger undefined behaviour.

Solution 1: Optimised Inserts

Before we accept connection requests from clients, lets look at what insert requests and query requests look like.

Now lets handle multiple client connections simultaneously.

Next, we implement the “handleClient” function.

We need to write 4 helper functions.

1. parseInsertRequest:

   

2. parseQueryRequest:

1. handleInsertRequest:

   Since we’re using a sorted set, adding a new node, or updating an existing one takes O(logN) time.

4. handleQueryRequest:

   The sorted set uses binary search to find the node with the least timestamp greater than or equal to minTime. It then linearly iterates through nodes while the timestamp <= maxTime.

   So retrieving a range of nodes within the [minTime, maxTime] interval takes O(N) time.

Solution 2: Optimised Queries

Thinking of using a prefix sum approach that reduces the time complexity of query requests, but increases the time complexity of the insert requests.

1. prefix sum for the i-th timestamp is:
   prefixSum[i] = price[0] + price[1] + . . . . + price[i]

2. Then finding the mean price of an asset between the j-th and i-th timestamp is easy:
   mean = (prefixSum[j] - prefixSum[i] + price[i]) / ( j - i )

3. Insert queries take longer time, as every time a timestamped price is inserted, the prefix sum of all timestamps ahead of it must be updated.
   

Implementation coming soon.

With a final blow, the beast collapses. We live to see another day!

We’re through to the first challenge, Prime Time. If you’d like to jump straight to my implementation, here’s the GitHub link.

Problem Requirements:

1. Build a server that accept TCP connections from multiple clients simultaneously.

2. Clients send requests in JSON format, separated by a newline character.

3. A request may be valid, or malformed.

   • A valid request has the following fields:

     • “method”: must always contain the string "isPrime".

     • “number”: must contain a number. Any JSON number is a valid number, including floating-point values.

     Note: Extraneous fields are to be ignored.

     Example valid request:

     

     A valid request warrants a valid response, and must have the following fields:

     • “method”: must always contain the string "isPrime".

     • “prime”: must contain a Boolean value: true if the number in the request was prime, false if it was not. (Floating point values, negative numbers and 1 are valid JSON numbers, but not prime numbers).

     
     Example valid response:

     

   • A request is malformed if:

     • It is not a well-formed JSON object.

     • Any required field is missing.

     • The method name is not "isPrime".

     • The number value is not a number.

     The server should respond to a malformed request, with a malformed response, and disconnect the client.

4. A client can send multiple requests one after the other. This means that the client can send a second request, without waiting to receive a response to the first one. The server needs to send responses in the same order in which it receives requests.

Solution:

Before we start accepting connections from clients, lets look at what a request and response should look like.

Lets deal with the first requirement, handling multiple client connection requests simultaneously.

Now that we can handle multiple clients, lets implement the function “handleClient”.

We now need to implement 2 functions.

1. validateRequest:

2. checkPrime:

Another victory in the books. On to the next!

This is the first in a series of posts where I explain my solutions to the famous “Protohacker Challenges”, a set of computer networking and web server challenges, each one harder than the last.

Before we confront the more formidable challenges, let’s test our swords in battle by completing the zeroth challenge, Smoke Test. I would advise that you read the problem statement first and try to come up with a list of requirements yourself.

If you’d like to skip to my solution, here’s the GitHub link.

Problem Requirements:

1. Build a server that accepts TCP connections on a port.

2. Echo any data sent by the client.

3. Handle at least 5 clients simultaneously.

4. Host the solution on a publicly accessible IP address and port, so protohackers can check your solution by sending requests. (I hosted my solution on a DigitalOcean droplet.)

Solution:

Lets begin by focusing on the first requirement, building a server that accepts TCP connections on a port.

We use the for loop to listen for connection requests from clients.

Once a connection has been established, we spawn a go-routine that’s responsible for interacting with the client that initiated the connection.

Using separate go-routines to deal with clients ensures that we can accept connections from new clients, and interact with the old ones simultaneously. This takes care of requirement 3.

Now that our server can accept TCP connections, lets look at requirement 2.

We need to echo all the data that we receive back to the client.

We may have tamed this beast, but greater challenges await. Onward!