GeeksSpot

HTTP History In 1989, the hypertext transfer protocol have been invented. HTTP/1.1 has been released in 1997 and took the longest pause in evolution. In 2015, Google has redrafted its inhouse SPDY protocol to HTTP/2 to optimize the web page load time.  HTTP/1.1 Pitfalls Too heavy and big protocol. Too many parts have been added as optional led to complicating the protocols with less of usage. Since HTTP1.1 release, web technology have seen tremendous change. Page size has been increased to MBs, the number to pages increased manifolds and parallel components making HTTP calls increased too.  Each HTTP request has a separate TCP connection and its handshake does add to page load time.  Head of line blocking has slowed the page load. We can have a maximum 8 parallel connection to the same domain. Due to increase in multiple components making separate HTTP calls, this has been a bottleneck.  HTTP/2 Solution Binary framing layer: HTTP/1.1 was text-only messaging, which was not efficient. HT

Google has developed gRPC in 2015 and released it for the world to use. gRPC has been evolved from Stubby,  which Google has been using for all internal communication.  gRPC is open-sourced high-performance RPC framework. It efficiently connects services across machines with pluggable support for load balancing, authentication, monitoring. It supports a wide range of programming language and it can be developed and deployed fast. Microservices architecture does support gRPC communication over service mesh and pretty efficient over REST.  Client libraries in 10 programming languages. gRPC Languages Bidirectional streaming and http/2 supported. pluggable load balancing, auth and monitoring.  Request response and streaming support are available. Strongly typed message definition using Protobuf.  gRPC work like a client-server model. The client will call the framework generated stub (client) to make a service request on a different machine. The server will take the request, execute the ser

How to make sure that the document is written by me and only me.  In a physical world, we usually signed under the document with our unique handwriting. Now the second party should identify that it is my signature. Still, chances are there, people will manipulate the content. To avoid the same we used to sign granular pieces of the information i.e. each page.  It is not easy to replace content in a single page. Not yet.  So this makes sure information is authenticated by me and can be quoted for me.       Now, how do we do the same practice in the virtual world? We use JWT (JSON WEB TOKEN).   A JSON web token is simply JSON payload containing a particular claim. It has three parts all separated by ".".  Header  Payload  Signature  Header: The header  typically  consists of two parts: the type of token, which is JWT, and the hashing algorithm that is used, such as HMAC SHA256 or RSA. Its base64 encoded string.  { "alg" : "HS256" , "typ" : &quo

How to make sure User A is User A as he claims, not User a. Our old movies smugglers can teach us a few tricks here. There are multiple levels or factor of authentication. 1. First Factor - Something you only know. It's like a secret pin, key, pattern or password.     In the old movie, there used to be a secret code between smugglers.  Parties involved in the transaction only knows this secret code. 2. Second Factor - Something you only own. It's like the ATM card, phone, device or OTP.      In the old movies, smugglers used torn currency note. Both parties will have one part.  One party need to show ownership of half of the torn currency note to receive goods from another party. 3.  Third Factor - Something you are. It's related to your physical appearance. Like your face, your thumb impression or voice. Your personal physical traits will be used to identify you.      Remember hero duplicates being used to catch smugglers. These were negative applications of t

I will try to explain consistent hashing with a real world example. Let's assume I have a restaurant with 60 tables and 5 servers (waiter). Each server is given an equal number of tables to serve. Now let's assume we have addition of a new server (waiter), so his addition will be marked in the circle and he will be receiving tables from the previous server to his distance only. Check the attached example. Assume a server (waiter) has left the organisation and we have only 4 servers now. Server3 has left the restaurant, so his table will be assigned to server 4. I am sure you have noticed the load is not equally distributed. But to make the system less prone to addition/removal we just rotate in clockwise and assign range from the previous server to present server.  To make sure load is balanced or optimally balanced we need to use virtual nodes. Check links here: http://tom-e-white.com/2007/11/consistent-hashing.html https://www.toptal.com/big-data/

In a web world, everything is available over the internet. While designing a distributed application for the client, we often face this dilemma of choosing between consistency and availability.  There is no further argument if we don't choose to have a partition tolerant system, that's single node application and it will adhere to consistency and availability. So we will be discussing Partition tolerant systems for a distributed environment.  Lets first understand CAP individual elements; C (Consistency):  In a distributed environment of n nodes, a change in one node should be instantly reflected all other nodes. So any data change/state should be reflected all client irrespective of whichever node they access the data.  A (Availability): All the non-failing node should be ready to serve any request within a reasonable time. This applies to every node present in the system.  P (Partition Tolerence): Distributed systems are meant to build partition tolerant syste

Why do we need any middleman if i can directly communicate to second computer. That's how Peer to peer communication works. You just need initial signaling to be done with the help of server. Create an offer from computer initiating communication, pass it to server which in turn check same with peer computer. Once peer acknowledge incoming request, it will share its SDP details. Once acknowledgement received with peer connection information, computer will be able to directly communicate with peer. Now in this post, I wish to talk about how WebRTC will be leveraged to implement multiparty video conferencing. Mesh: In this architecture every participant have a connection to each other. So for n participant will have n-1 connection. So total n*(n-1)/2 connections. This is easy to implement as it does not need much changes from existing P2P connection. All the stream handling is done at edge computer. It has drawback of high data consumption and scalability issues.