This week I have:

• Learned about the P2P and different Protocols in the implementation
• Learned about the history of P2P, and different architectures in implementing a fully functional P2P File Sharing Application. It is quite colorful actually.
• Made a rough draft of Outline Proposal
• Learned about design patterns in Elixir. I am still very very new to the language. The backend architecture of Elixir is actually a lot different from all the web servers backend I have seen.
  • The code is really really tight – there is should be no place for redundancy, ever. A good Elixir code should be decoupled as much as possible for scaling later.
  • Perfect for real-time processing, and concurrency handling. – An absolutely perfect choice for this project. Fun fact, Elixir is built on top of Erlang VM. And Erlang is what helped WhatsApp become the WhatsApp we know today – at times WhatsApp had 1 million new users every day – and the scaling power of Erlang enabled instantaneous communication, with little to no failure of nodes. AT&T also used Erlang as its backbone for telecommunication – in Erlang, your application still runs while being updated! (That’s why you can make phone calls why AT&T updates their software in the background – mindblown!)
  • Supervision tree which automatically respawns failing nodes/processes –> guarantee availability.
  • Running on Erlang VM means the code in Elixir is compiled into Erlang bytecode, which runs on BEAM VM. Erlang processes are implemented entirely by the Erlang VM and have no connection to either OS processes or OS threads. So even if you are running an Erlang system of over ten million processes it is still only one OS process and one thread per core and completely isolated to your actual OS. Amazing!
  • There are more wonderful things about Elixir but I guess I stop ranting here.
• I am trying to scale my current implementation of Baby Distributed Hash Table (still very early stage and primitive) to more nodes but there are some unexpected bugs that I have to study further. The Distributed Hash Table will become a crucial part of the query later in my application, along with the Merkle Tree.
• I am studying the architecture of Napster – the killer P2P application that appears in the early 2000s that paved the way to P2P. However, I kinda want to improve/ or rather try with a slightly modified architecture – to negate the delegator/gateway node to make my system completely decentralized to absolutely destroy the single point of failure. I am not sure if this is possible. I might not have time to actually implement it in the near future but might be good to keep in mind.

Next week:

• Continue with studying Elixir. The more I learn about it, the more I fall in love with this language. So elegant yet doing so much.
• Continue to do more research on applications that have P2P architectures. I already saw some “grid architecture”, which is slightly different from P2P but have not taken a deep dive in it yet. So perhaps one of the things to look at. I have also looked at some apps other than Napster, and I wonder why most of them were implemented for Windows.
• Contemplate over the current architecture that I have in mind and its purpose. Most of the P2P apps have faced a challenge in the legal issues regarding copyright. I guess I have to repurpose my app such that no such thing would happen if I decide to do hardcore and actually deploy it into use.