# Week 13

## Recap
This week was a fairly heavy week in terms of actual implementation work. I was able to get a lot of things out of the way that are needed to have a working Portal Wire implementation. Both in terms of completed code as well as a design plan. To start the week, I at last merged all of my Portal Client work into the Samba repository under a merge branch. I hope to go over the PR with Meldsun at the start of the coming week to ensure there are no conflicts in uncommited code. The merge included main components such as the CLI implementation, any required additional configuration for the network interactions as well as the dedicated proper bootnode setup. Following up from the previous week, I was very fortunately able to find a way to directly interact with TALKREQ and TALKRESP messages without the need for any modifications to the Consensys Discovery library. Designing an appropriate handler for such interactions was the primary focus for the remainder of the week. I ended up creating a two part design for all Portal Wire interactions. Because Portal Wire packets inherit the same intention as TALKREQ and TALKRESP messages, I could break the message handling into incoming and outgoing requests. From there it becomes just a matter of handling each situation according to the Portal Wire packet recieved.

## Learning
There was not a large amount of new information to cover this week, most of which was just an extenstion of what I was researching last week on the Consensys Discovery library. Except I was able to find the solution I needed to move forward which was a big accomplishment.

### Concepts

#### Consensys Discovery V5
I found the solution to my problem I was facing last week through the use of the libraries dedicated TalkHandler class. The handler was designed to function with an application using the Discovery library, which fit my exact needs. I also entirely figured out the libraries message flow through the incoming pipeline which was useful in designing parts of the handler for Samba. Looking through the message flow is also what prompted me to come up with a two part design, one main handler for all TalkHandler interactions and another for interacting with the DiscoverySystem outgoing talk() method.

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

## Tasks
As mentioned above, part of this weeks implementation was migrating work from my Portal Client into the Samba repository, as well as linking everything together in the systems design. Though the main implementation work had to do with creating and partially implementing the sepparated incoming/outgoing handler. The idea originated from the fact that all Portal Wire packets asking for information or initiating interaction go through TALKREQ, whereas all responses go through TALKRESP. Throughout this week, I mainly focused on the client interactions that deal with incoming TALKREQ packets as well as sending the corresponding response through TALKRESP. I also wanted to be mindful of the other case, where the client sends TALKREQ to a given node, and then recieves TALKRESP. Fortunetely that part is dealt with a bit more by the Discovery library. In general the design works on a few levels, this multi-level design should also make it easier to have more than one Portal Sub-network opperating at once. The design is as such:

1. At the top level the PortalNodeMainService created by Meldsun initializes a set of Portal handlers that I designed (PortalWireMessageProcessor and a PortalDiscoveryMessageHandler initialized using the message processor), as well as the DiscV5Service also created by Meldsun. When the DiscV5Service is created, I enabled it to accept the handlers created in the PortalNodeMainService
2. Inside the DiscV5Service, the actual DiscoverySystem from the Consensys library is created. Using the build tool to create the DiscoverySystem I can then configure it to use the PortalDiscoveryMessageHandler to deal with all incoming TALKREQ messages
3. When a TALKREQ message is recieved it is passed through the DiscoveryService to the PortalDiscoveryMessageHandler which then begins the parsing process.
4. The first part of this process is to send it to a decoder to both decode the message from SSZ and then identify the message type (This portion is still in the works)
5. Once the Message is decoded it can be passed to the PortalWireMessageProcessor which then sends the message to its corresponding MessageType handler.
6. Once handled the MessageType handler just needs to return its response all the way up the chain, until the Discovery library puts it in a TALKRESP packet and returns to the node that initiated the communication.

I when designing this system I wanted to make sure that the PortalWireMessageProcessor could also be re-used in outgoing TALKREQ interactions. The varying level design should also enable the tracking of node tables for each Sub-network once they are implemented.

https://github.com/meldsun0/samba/tree/ExternalPortalClientMigration

## Week 14 Plan
Heading into Week 14, I have a nicely straightforward path to continuing implementation. I am hoping to:
- Create the PortalWireMessageDecoder using the Tuweni SSZ library to decode incoming Portal Wire packets.
- Enable packet specific SSZ serialization to meet the Portal Wire specifications
- Start on specific incoming packet responses, although some of such response implementations will have to wait for when the History Sub-network is being created
- Start working on the other side of the main Portal Wire handler meant for sending outgoing packets and dealing with the corresponding responses

I am also hoping to briefly go over my client merge PR with Meldsun to ensure there are no conflicts before I merge it into the Samba main branch.