# Week 14 ## Recap This week was much the same as the previous in that it was primarily implementation work. I mainly focused on the actual data processing of incoming Portal Wire packets so that the client can have actual values to work with. In order to do so I had to look through and learn how to use Apache's Tuweni SSZ library so I could handle incoming packet deserialization. From there it was a matter of figuring out what data types to use to store the deserialized data. Because the types specified in SSZ do not necesarily align with the types provided by Java I had to use a mix of the data types provided in the Tuweni repository and default Java types. As in some cases the types provided by Tuweni did not match up with what was being produced by the decoding part of the SSZ library. To get around that I found that I could use the Java library so long as I ensured that the SSZ decoded data did not actually need certain properties such as being stored as unsigned values. I just needed to ensure that the transition was lossless and could then abstract away the need for a data type to be unsigned. Though this also means that as I work on packing things away through serialization I have to double check that the values are preserved when put back into SSZ form. ## Learning All of my learning this week came from looking through the Tuweni SSZ library in conjunction with the Portal Wire specification repository to learn how to properly decode each packet. Looking through the Tuweni library was also useful in finding out a general idea of what data type I could store the decoded information as. ### Concepts #### Tuweni SSZ My primary focus when looking into the library was learning about the decoding methods located in the SSZ class. As there are various different SSZ specified data types that can be decoded, I needed to find every method required for decoding a given packet type. This was also useful in figuring out how I actually pass the byte data to the library so it could be properly translated to the corresponding value. ##### Resources 1. https://github.com/apache/incubator-tuweni/tree/main/ssz #### Portal Wire Specifications The specifications were necessary not just for determining which packet is decoded into what set of data types, but also helpful in determining how I could abstract values that had no proper data type implementation. I also found it usefule to look through the provided test vectors to get an idea of how the SSZ selectors are used. This then allowed me to properly parse each packet and send the remaining data to the correct decoder. ##### Resources 1. https://github.com/ethereum/portal-network-specs/blob/master/portal-wire-protocol.md 2. https://github.com/ethereum/portal-network-specs/blob/master/portal-wire-test-vectors.md ## Tasks In terms of implementation for the week, I completed the packet deserialization work and began working on the serialization of packets. When the serialization process is complete the client will then be able to read and store all incoming information recieved by external Portal Clients. As well as send information that can be read and interpreted by external Portal Clients. When working on packet design I wanted to find a way to have all packets being processed (whether incoming or outgoing) to be stored as a PortalWireMessage. In this way it would be both easy to test the packets as I could just compare two PortalWireMessage packets, and also then streamline how packets are passed around inside the client. Now that I am working on the serialization of the packets this design decision makes more sense as I am adding a serialize() method to each packet. This method should just return the packet in SSZ serialized byte form, which can then be sent out over the Portal Wire to other clients. It also means that the handler does not actually need to know the packet type to serialize it, as all packets implement PortalWireMessage, simplifying the outgoing messaging process. https://github.com/meldsun0/samba/pull/2 https://github.com/meldsun0/samba/commit/d884842948c7412f2ad8f7c0f02ae46f32233d51 ## Week 15 Plan Progressing into Week 15 my goals are fairly similar from the previous week. I am mostly looking to continue with implementation regarding the Portal Wire Protocol. Including tasks such as: - Continue implementing packet specific SSZ serialization to meet the Portal Wire specifications - Continue working on specific incoming packet responses - Design the other side of the main Portal Wire handler meant for sending outgoing packets and dealing with the corresponding responses I am also looking to put an emphasis on testing as I move forward, as the Portal Wire implementation is beginning to reach a point where it can interact with other Portal clients. Once I am complete the packet specific SSZ serialization I will likely add unit tests for both the deserialization and serialization to ensure that the incoming and outgoing packets are formatted properly. I should be able to use the test vectors provided in the Portal Wire specifications to do so.