# Week 12

## Recap
For most of this week my focus was continuing working on and designing a Portal Wire Protocol handler for the Portal Client. I ended up doing a lot of digging through the Consensys Discovery library and was faced with a number of different design choices to make. The first of such choices was how to set up the handler in a way to compartmentalize its different interactions with other nodes and be able to handle different requests. After meeting with Meldsun on a call it was decided that the client would best function in a manner that entirely segmented the actual communication end of things and RPC requests for the Portal Sub-networks. Fortunately this didn't really impact the design of how each Portal Wire packet would be handled, but it did raise a question about how the actual message packets that were transferred from the Discovery library should be handled. Because Portal Wire functions entirely inside the TALKREQ and TALKRESP packets from Discovery, there is really only a need to focus specifically on those packets. I had also realized that the Consensys Discovery library handles all of the node storage and handshake verification that the Portal Wire protocol assumes is set up, which removed the need to create a dedicated version of a DHT for the protocol.

Going back to the need for processing TALKREQ and TALKRESP Discovery packets, there are essentially two choices I had. I could create an additional service that runs independently of Discovery and filter through all packets, or I could insert my own TALKREQ/TALKRESP handler into the Discovery libraries pipeline to specifically act on the relevant packets and send them to my handler to then process the Portal Wire packet inside them. I opted to work on the second choice, as if it was possible would drastically streamline the entire messaging process and skip the need create an extra service. It could then also enjoy the same optimizations employed in the Discovery library without having to re-implement them. So I started to design my handler to then inject into the Discovery system and essentially completed it. Only to find that the Consensys Discovery library was not designed with the intent to be built upon, as I began running into scope issues through different private scoped services. I met with Meldsun again and we discussed a way to circumvent this issue, which essentially left two options again, create a new service as mentioned before, or fork the library and add our own custom support for Portal Wire. We ultimately decided it would be best to just fork the repository and add custom support. However, over the weekend I spoke with a member of the team responsible for designing the Trin Portal Client, and it turns out the Trin team had a similar problem with the Rust Discovery library they used. Instead of forking they actually just got into contact with the owners of the library and opened a PR to include add-on support, which solved the problem. I am hoping to look into doing the same with the Consensys library, or perhaps finding a way to add in my handler if the library developers have included a way to do so that I have missed.

## Learning
Most of my learning this week was done by continuing to read through the Consensys Discovery library. I started of by checking if it had the capability to handle a few requirements that the Portal Wire Protocol needs and moved on to networking details. I did a bit of brushing up with Javas Completable Future package and thread handling as it is found throughout the Discovery library and I have only minimally used it in the past.

### Concepts

#### Consensys Discovery V5
When looking through the repository and code this week I began by searching to see how the library handled node storage through its DHT implementation. After playing around with the node stats in the Portal Client I realized that it actually handled everything Portal Wire needed for node storage wise so there wasn't a need to continue developing an external DHT implementation. I also found that all nodes featured in the storage are automatically validated through the Discovery handshake eliminating the need to handle that. Moving to a different point of research, I began looking in depth at the design of the Discovery System class and its corresponding Discovery Manager class. Which led me to learn about the libraries pipeline design for incoming and outgoing packets, the use of sepparate Netty client and server services, and the packet processor. I was looking through these with the intent to find a way to inject an additional handler to use for forwarding TALKREQ and TALKRESP packets.

##### Resources
1. https://github.com/Consensys/discovery

## Tasks
Outside of research, I continued working on a Portal Wire Protocol handler, and related pieces to allow Portal Client communication. I was able to get a working messaging system using the TALKREQ and TALKRESP packets provided by discovery, however in order to properly communicate to other Portal Nodes I will have to implement SSZ serialization. Fortunately I was able to find a library and will start looking into its use. I also began developing an extension of the existing Discovery handlers to function with a TALKREQ/TALKRESP handler made to specifically forward the packets to the Portal Wire handler for processing. I ran into scoping issues with the library, but once they are sorted the extension should work as intended. I met with Meldsun twice this week to discuss repository syncing and client service design, we agreed to postpone full repository syncing for an additional week to allow for him to finish his client services design.

https://github.com/Dsorken/Java-Portal-Client/tree/discv5toportalwiresupport

## Week 13 Plan
Moving to Week 13 I have a fairly straightforward set of goals, but once complete should shoot our client progress from minimal communication with discovery nodes, to being able to properly communicate with specifically Portal Clients. This includes:
- Either opening a PR on the Consensys Discovery library to support the ability to add on to the service, or finding a way to do so without a PR from the library developers
- Using the Tuweni SSZ library to enable TALKREQ/TALKRESP payload serialization
- Continuing to design a Portal Wire handler, hopefully to at least handle Portal Wire Ping and Pong interactions for POC
- Sync repository into Meldsun's Samba repository
Once those are complete the client should be able to communicate with other Portal Clients over Portal Wire and I can then work on completing the additional packet messages needed for the Portal Sub-networks.