gRPC - Quick Refresher

gRPC is a high performance, open source RPC framework initially developed by Google. It helps in eliminating boilerplate code and helps in connecting multiple services in and across data centers. It’s open-source, free-to-use and available on many different development platforms.

The framework is based on a client-server model of remote procedure calls. A client application can directly call methods on a server application as if it was a local object.

gRPC embraces HTTP semantics over HTTP/2, allows for client-server and duplex streaming of data and relies on protocol buffers(protobuf) as a serialization mechanism that allows it to be efficient. It provides low-latency and highly distributed systems such as microservices due to its efficiency, we can call remote methods the same way we call normal methods.

A number of different organizations have adopted gRPC, such as Square, Netflix, CoreOS, Docker, CockroachDB, Cisco, Nokia and Juniper Network and many more for streaming network telemetry instead of using SNMP. Stay tuned for the next post covering telemetry uses cases by using gRPC in networking.


Click Here To Read Rest Of The Post...

Basics of HTTP: HTTP/1.1 and HTTP/2.0 - Required For Telemetry

Remote Procedure Calls (RPC) is not a protocol, it's a principle that is also used in SOAP. SOAP is an application protocol that uses HTTP for transport. HTTP (Hypertext Transfer Protocol) is the most popular client-server application-level protocol used in the Internet. As from RFC2616: "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers".

Being stateless, the new request doesn't know what has been sent in the previous request. It is purely based on pull model, which means server will only share that information what is being requested by client. It negotiates of data type and it's representation, so as to allow systems to be built independently of the data being transferred.

It typically runs over a TCP/IP connection and requires a reliable transport. But any transport protocols that provide such reliable delivery can be used.

There are 2 classes of HTTP Protocol. HTTP/1.0 is the initial major version of HTTP network protocol. HTTP/2 (originally names HTTP/2.0) is subsequent major version of HTTP. HTTP 1.0 was sensitive to high latency connections, as every request had to be made sequentially. If two requests made simultaneously, you had to wait until the first was completed before making the second.

HTTP 1.1 improved this, by enabling pipelining. If the user wanted to make simultaneously two requests, they could send off both requests and then receive the responses back in order. However this suffered from head-of-line blocking problem, consequences intensive or slow request completed.

HTTP/2 aims to address these issues by changing how the client and server communicate over the wire. To do this it introduces two new concepts: frames and streams:
Frames: The smallest unit of communication in HTTP/2, each containing a frame header, which at a minimum identifies the stream to which the frame belongs.
Stream: A bidirectional flow of bytes within an established connection, which may carry one or more messages.
Message: A complete sequence of frames that map to a logical request or response message.

The utmost focus of HTTP/2 is performance, especially latency as perceived by the end-user while using a browser, with a secondary focus on network and server resource usage. One large benefit of HTTP/2 is the ability to use a single TCP connection from a browser to a website as compared to multiple TCP connections in HTTP/1.1. HTTP/2 uses push model as compared to pull model used by HTTP/1.1. A single TCP connection is all that’s required because HTTP/2 leverages multiplexing and allows asynchronous (parallel) requests. Image credit goes to stackoverflow.

Excerpt from High Performance Browser Networking: HTTP/2 does not modify the application semantics of HTTP in any way. All the core concepts, such as HTTP methods, status codes, URIs, and header fields, remain in place. Instead, HTTP/2 modifies how the data is formatted (framed) and transported between the client and server, both of which manage the entire process, and hides all the complexity from our applications within the new framing layer. As a result, all existing applications can be delivered without modification.

It is important to note that HTTP/2 is extending, not replacing, the previous HTTP standards. The application semantics of HTTP are the same without having any changes in the core HTTP concept. While the high-level API remains the same, it is important to understand how the low-level changes address the performance limitations of the previous protocols. Let’s take a brief tour of the binary framing layer and its features.


Click Here To Read Rest Of The Post...

Remote Procedure Call - Starting Telemetry

Remote procedure call (RPC) architecture is popular in building salable and distributed client/server model applications. RPC allows a client to a make procedure call to a server on a different address space without understanding the network configuration as if the server was in the same network (making a local procedure call). RPC packages all have a simple goal: to make the process of executing code on a remote machine as simple and straightforward as calling a local function. Thus, to a client, a procedure call is made, and some time later, the results are returned. The server simply defines some routines that it wishes to export. The rest of the magic is handled by the RPC system, which in general has two pieces: a stub generator (sometimes called a protocol compiler), and the run-time library.

The earliest computing models utilizing Remote Procedure Calls to frame network operations dates back to early ARPANET documents in the 1970’s, with practical applications of the technology appearing in the 1980’s. The term itself was coined by Bruce Jay Nelson in 1981, and was used to describe the system, saying: "Remote procedure call is the synchronous language-level transfer of control between programs in disjoint address spaces (Local and Remote) whose primary communication medium(TCP/IP/UDP) is a narrow channel."

RPC is a protocol that allows one to relay problems in the same format regardless of whether it is being calculated locally or remotely.

Below is the list of advantages of Remote Procedure Call:
1. RPC supports process oriented and thread oriented models.
2. Internal messaging Pipeline of RPC is hidden from the user.
3. Uses more computational power.
4. Built for local as well as for distributed environment.
In the next post, I will be covering more about gRPC (google remote procedure call). So stay tuned.
Click Here To Read Rest Of The Post...