Read Anytime Anywhere Easy Ebook Downloads at ebookmeta.

com

Network Programming with Go Language : Essential

Skills for Programming, Using and Securing
Networks with Open Source Google Golang 2nd
Edition Jan Newmarch
https://ebookmeta.com/product/network-programming-with-go-
language-essential-skills-for-programming-using-and-
securing-networks-with-open-source-google-golang-2nd-
edition-jan-newmarch/

OR CLICK HERE

DOWLOAD EBOOK

Visit and Get More Ebook Downloads Instantly at https://ebookmeta.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Network Programming with Go Language : Essential Skills

for Programming, Using and Securing Networks with Open
Source Google Golang 2nd Edition Jan Newmarch
https://ebookmeta.com/product/network-programming-with-go-language-
essential-skills-for-programming-using-and-securing-networks-with-
open-source-google-golang-2nd-edition-jan-newmarch/
ebookmeta.com

Network Programming with Go Language 2nd Edition Ronald

Petty

https://ebookmeta.com/product/network-programming-with-go-
language-2nd-edition-ronald-petty/

ebookmeta.com

Software Development with Go: Cloud-Native Programming

using Golang with Linux and Docker Nanik Tolaram

https://ebookmeta.com/product/software-development-with-go-cloud-
native-programming-using-golang-with-linux-and-docker-nanik-tolaram/

ebookmeta.com

Anoikis How the Extracellular Matrix Regulates Life or

Death Decisions 1st Edition Steven M. Frisch

https://ebookmeta.com/product/anoikis-how-the-extracellular-matrix-
regulates-life-or-death-decisions-1st-edition-steven-m-frisch/

ebookmeta.com
IoT, Machine learning and Blockchain Technologies for
Renewable Energy and Modern Hybrid Power Systems 1st
Edition C. Sharmeela
https://ebookmeta.com/product/iot-machine-learning-and-blockchain-
technologies-for-renewable-energy-and-modern-hybrid-power-systems-1st-
edition-c-sharmeela/
ebookmeta.com

National Geographic Traveler Florence and Tuscany 3rd

Edition Tim Jepson

https://ebookmeta.com/product/national-geographic-traveler-florence-
and-tuscany-3rd-edition-tim-jepson/

ebookmeta.com

Fates and Furies Lauren Groff

https://ebookmeta.com/product/fates-and-furies-lauren-groff/

ebookmeta.com

Mountain Daddy's Milk & Honeymoon (Spice in the Mountains

Book 2) 1st Edition Elena Dawne

https://ebookmeta.com/product/mountain-daddys-milk-honeymoon-spice-in-
the-mountains-book-2-1st-edition-elena-dawne/

ebookmeta.com

The Bastard Complete Series 1st Edition Jack Porter

https://ebookmeta.com/product/the-bastard-complete-series-1st-edition-
jack-porter/

ebookmeta.com
Forming Humanity Redeeming the German Bildung Tradition
1st Edition Jennifer A. Herdt

https://ebookmeta.com/product/forming-humanity-redeeming-the-german-
bildung-tradition-1st-edition-jennifer-a-herdt/

ebookmeta.com
Jan Newmarch and Ronald Petty

Network Programming with Go

Language
Essential Skills for Programming, Using and
Securing Networks with Open Source Google
Golang
2nd ed.
Dr. Jan Newmarch
Oakleigh, VIC, Australia

Ronald Petty
San Francisco, CA, USA

ISBN 978-1-4842-8094-2 e-ISBN 978-1-4842-8095-9

https://doi.org/10.1007/978-1-4842-8095-9

© Jan Newmarch and Ronald Petty 2022

This work is subject to copyright. All rights are reserved by the

Publisher, whether the whole or part of the material is concerned,
specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other
physical way, and transmission or information storage and retrieval,
electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed.

The use of general descriptive names, registered names, trademarks,

service marks, etc. in this publication does not imply, even in the
absence of a specific statement, that such names are exempt from the
relevant protective laws and regulations and therefore free for general
use.

The publisher, the authors and the editors are safe to assume that the
advice and information in this book are believed to be true and accurate
at the date of publication. Neither the publisher nor the authors or the
editors give a warranty, expressed or implied, with respect to the
material contained herein or for any errors or omissions that may have
been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.
This Apress imprint is published by the registered company APress
Media, LLC, part of Springer Nature.
The registered company address is: 1 New York Plaza, New York, NY
10004, U.S.A.
I dedicate this to my family.
Preface to the Second Edition
While an age has passed in Internet years, Go remains a primary
destination for programmers. Go conquered the container technology
space. It continues to find affection in Cloud Native development. Go
strives to remain true to itself, backward compatible, yet adding new
language features like Generics. Tooling improvements such as Fuzzing
allow for more secure application development.
Go has changed, and so has this book. The first edition used Go 1.8;
we are now on Go 1.18. The code has been updated to reflect this new
reality. The examples have been largely developed to show a particular
feature of Go networking without forcing complexity like managing
several projects or packages scattered across the book; the associated
repository can be found here
https://github.com/Apress/network-prog-with-go-2e.
The first version of this book assumed familiarity with Go, and that
remains in this edition. We expand slightly what we are willing to
discuss in this book with the inclusion of more third-party modules,
tools, and techniques. Jan was correct to keep the focus on Go and not
to be distracted with the ecosystem at large.
If you desire to learn about implementing networking concepts with
Go, I hope this book serves you well.
As a point of comparison, what follows is Jan’s original preface,
reflecting Go in 2017.
Preface to the First Edition
It’s always fun to learn a new programming language, especially when it
turns out to be a major one. Prior to the release of Go in 2009, I was
teaching a Master’s level subject in network programming at Monash
University. It’s good to have a goal when learning a new language, but
this time, instead of building yet another wine cellar program, I decided
to orient my lecture notes around Go instead of my (then) standard
delivery vehicle of Java.
The experiment worked well: apart from the richness of the Java
libraries that Go was yet to match, all the programming examples
transferred remarkably well, and in many cases were more elegant than
the original Java programs.
This book is the result. I have updated it as Go has evolved and as
new technologies such as HTTP/2 have arisen. But if it reads like a
textbook, well, that is because it is one. There is a large body of
theoretical and practical concepts involved in network programming
and this book covers some of these as well as the practicalities of
building systems in Go.
In terms of language popularity, Go is clearly rising. It has climbed
to 16th in the TIOBE index, is 18th in the PYPL (Popularity of
Programming Language), and is 15th in the RedMonk Programming
Language rankings. It is generally rated as one of the fastest growing
languages.
There is a growing community of developers both of the core
language and libraries and of the independent projects. I have tried to
limit the scope of this book to the standard libraries only and to the
“sub-repositories” of the Go tree. While this eliminates many excellent
projects that no doubt make many programming tasks easier,
restricting the book to the official Go libraries provides a clear bound.
This book assumes a basic knowledge of Go. The focus is on using
Go to build network applications, not on the basics of the language.
Network applications are different than command-line applications, are
different than applications with a graphical user interface, and so on. So
the first chapter discusses architectural aspects of network programs.
The second chapter is an overview of the features of Go that we use in
this book. The third chapter on sockets covers the Go version of the
basics underlying all TCP/IP systems. Chapters 4, 5, and 6 are more
unusual in network programming books. They cover the topics of what
representations of data will be used, how a network interaction will
proceed, and for text, which language formats are used. Then in Chapter
7, we look at the increasingly important topic of security. In Chapter 8,
we look at one of the most common application layer protocols in use,
HTTP. The next four chapters are about topics related to HTTP and
common data formats carried above HTTP – HTML and XML. In
Chapter 13, we look at an alternative approach to network
programming, remote procedure calls. Chapters 14 and 15 consider
further aspects of network programming using HTTP.
Any source code or other supplementary material referenced by the
author in this book is available to readers on GitHub. For more detailed
information, please visit
https://github.com/Apress/network-prog-with-go-2e.
Acknowledgments
I want to share my appreciation for Jan Newmarch for collaborating on
this book. This project has offered me a tremendous sense of
achievement and allowed me to cross a much-anticipated item off my
bucket list. I would also like to thank Eldon Alameda for his thoughtful
approach at letting me know when I am off the mark and for providing
me with solid advice.
Additionally, I owe gratitude to my partners at Apress, both Steve
Anglin for the opportunity and Mark Powers for the guidance to help
see this through. Thank you to my colleagues at RX-M, including Randy
Abernethy, Christopher Hanson, Andrew Bassett, and Anita Wu. Our
work over the years has allowed for my participation in a project such
as this book.
Finally, I want to thank my wife Julie and daughter Charlotte. Julie’s
capacity to manage the world while I hide out on a computer is
unmatched and most appreciated. Charlotte’s energy, abilities, and
creativity inspire me to become better every day.

—Ronald Petty
Table of Contents
Chapter 1:​Architectural Layers
Protocol Layers
ISO OSI Protocol
OSI Layers
TCP/​IP Protocol
Some Alternative Protocols
Networking
Gateways
Host-Level Networking
Packet Encapsulation
Connection Models
Connection Oriented
Connectionless
Communications Models
Message Passing
Remote Procedure Call
Distributed Computing Models
Client-Server System
Client-Server Application
Server Distribution
Communication Flows
Synchronous Communication
Asynchronous Communication
Streaming Communication
Publish/​Subscribe
Component Distribution
Gartner Classification
Three-Tier Models
Fat vs.​Thin
Middleware Model
Middleware Examples
Middleware Functions
Continuum of Processing
Points of Failure
Acceptance Factors
Thoughts on Distributed Computing
Transparency
Access Transparency
Location Transparency
Migration Transparency
Replication Transparency
Concurrency Transparency
Scalability Transparency
Performance Transparency
Failure Transparency
Eight Fallacies of Distributed Computing
Fallacy: The Network Is Reliable
Fallacy: Latency Is Zero
Fallacy: Bandwidth Is Infinite
Fallacy: The Network Is Secure
Fallacy: Topology Doesn’t Change
 Fallacy: There Is One Administrator
Fallacy: Transport Cost Is Zero
Fallacy: The Network Is Homogeneous
Conclusion
Chapter 2:​Overview of the Go Language
Types
Slices and Arrays
Maps
Pointers
Functions
Structures
Methods
Multithreading
Packages
Modules
Type Conversion
Statements
GOPATH
Running Go Programs
Standard Libraries
Error Values
Conclusion
Chapter 3:​Socket-Level Programming
The TCP/​IP Stack
IP Datagrams
UDP
 TCP
Internet Addresses
IPv4 Addresses
IPv6 Addresses
IP Address Type
Using Available Documentation and Examples
The IPMask Type
Basic Routing
The IPAddr Type
Host Canonical Name and Addresses Lookup
Services
Ports
The TCPAddr Type
TCP Sockets
TCP Client
A Daytime Server
Multithreaded Server
Controlling TCP Connections
Timeout
Staying Alive
UDP Datagrams
Server Listening on Multiple Sockets
The Conn, PacketConn, and Listener Types
Raw Sockets and the IPConn Type
Conclusion
Chapter 4:​Data Serialization
 Structured Data
Mutual Agreement
Self-Describing Data
Encoding Packages
ASN.​1
ASN.​1 Daytime Client and Server
JSON
A Client and A Server
The Gob Package
A Client and A Server
Encoding Binary Data As Strings
Protocol Buffers
Installing and Compiling Protocol Buffers
The Generated personv3.​pb.​go File
Using the Generated Code
Conclusion
Chapter 5:​Application-Level Protocols
Protocol Design
Why Should You Worry?​
Version Control
The Web
Message Format
Data Format
Byte Format
Character Format
A Simple Example
 A Stand-Alone Application
The Client-Server Application
The Client Side
Alternative Presentation Aspects
The Server Side
Protocol:​Informal
Text Protocol
Server Code
Client Code
Textproto Package
State Information
Application State Transition Diagram
Client-State Transition Diagrams
Server-State Transition Diagrams
Server Pseudocode
Conclusion
Chapter 6:​Managing Character Sets and Encodings
Definitions
Character
Character Repertoire/​Character Set
Character Code
Character Encoding
Transport Encoding
ASCII
ISO 8859
Unicode
 UTF-8, Go, and Runes
UTF-8 Client and Server
ASCII Client and Server
UTF-16 and Go
Little-Endian and Big-Endian
UTF-16 Client and Server
Unicode Gotchas
ISO 8859 and Go
Other Character Sets and Go
Conclusion
Chapter 7:​Security
ISO Security Architecture
Functions and Levels
Mechanisms
Data Integrity
Symmetric Key Encryption
Public Key Encryption
X.​509 Certificates
TLS
A Basic Client
Server Using a Self-Signed Certificate
Conclusion
Chapter 8:​HTTP
URLs and Resources
i18n
HTTP Characteristics
 Versions
HTTP/​0.​9
HTTP/​1.​0
HTTP 1.​1
HTTP Major Upgrades
HTTP/​2
HTTP/​3
Simple User Agents
The Response Type
The HEAD Method
The GET Method
Configuring HTTP Requests
The Client Object
Proxy Handling
Simple Proxy
Authenticating Proxy
HTTPS Connections by Clients
Servers
File Server
Handler Functions
Bypassing the Default Multiplexer
HTTPS
Conclusion
Chapter 9:​Templates
Inserting Object Values
Using Templates
 Pipelines
Defining Functions
Variables
Conditional Statements
The html/​template Package
Conclusion
Chapter 10:​A Complete Web Server
Browser Site Diagram
Browser Files
Basic Server
The listFlashCards Function
The manageFlashCards​Function
The Chinese Dictionary
The Dictionary Type
Flashcard Sets
Fixing Accents
The ListWords Function
The showFlashCards Function
Presentation on the Browser
Running the Server
Conclusion
Chapter 11:​HTML
The html/​template Package
Tokenizing HTML
XHTML/​HTML
JSON
 Conclusion
Chapter 12:​XML
Unmarshalling XML
Marshalling XML
Parsing XML
The StartElement Type
The EndElement Type
The CharData Type
The Comment Type
The ProcInst Type
The Directive Type
XHTML
HTML
Conclusion
Chapter 13:​Remote Procedure Call
Go’s RPC
HTTP RPC Server
HTTP RPC Client
TCP RPC Server
TCP RPC Client
Matching Values
JSON
JSON RPC Server
JSON RPC Client
Conclusion
Chapter 14:​REST
 URIs and Resources
Representations
REST Verbs
The GET Verb
The PUT Verb
The DELETE Verb
The POST Verb
No Maintained State (That Is, Stateless)
HATEOAS
Representing Links
Transactions with REST
The Richardson Maturity Model
Flashcards Revisited
URLs
ServeMux (The Demultiplexer)
Content Negotiation
GET /​
POST /​
Handling Other URLs
The Complete Server
Client
Using REST or RPC
Conclusion
Chapter 15:​WebSockets
WebSockets Server
The golang.​org/​x/​net/​websocket Package
 The Message Object
The JSON Object
The Codec Type
WebSockets over TLS
WebSockets in an HTML Page
The github.​com/​gorilla/​websocket Package
Echo Server
Echo Client
Conclusion
Chapter 16:​Gorilla
Middleware Pattern
Standard Library ServeMux Examples
Customizing Muxes
gorilla/​mux
Why Should We Care
Gorilla Handlers
Additional Gorilla Examples
gorilla/​rpc
gorilla/​schema
gorilla/​securecookie
Conclusion
Chapter 17:​Testing
Simple and Broken
httptest Package
Below HTTP
Leveraging the Standard Library
 Conclusion
Appendix A:​Fuzzing
Fuzzing in Go
Fuzzing Failures
Conclusion
Appendix B:​Generics
A Filtering Function Without Generics
Refactor Using Generics
Custom Constraints
Using Generics on Collections
How Not to Use Generics?​
Conclusion
Index
About the Authors
Jan Newmarch
was head of ICT (higher education) at
Box Hill Institute before retiring, and still
is adjunct professor at Canberra
University, and adjunct lecturer in the
School of Information Technology,
Computing and Mathematics at Charles
Sturt University. He is interested in more
aspects of computing than he has time to
pursue, but the major thrust over the last
few years has developed from user
interfaces under UNIX into Java, the Web,
and then into general distributed
systems. Jan developed a number of
publicly available software systems in these areas. For the last few
years, he had been looking at sound for Linux systems and
programming the Raspberry Pi’s GPU. He is now exploring aspects of
the IoT and Cyber Security. He lives in Melbourne, Australia, and enjoys
the food and culture there, but is not so impressed by the weather.

Ronald Petty, M.B.A.,M.S.

is a principal consultant at RX-M and
founder of Minimum Distance LLC. He is
interested in many aspects of computing
including distributed systems and
machine learning. Kubernetes and Go
have occupied much of his time in recent
years, including presenting at KubeCon.
He hopes his own experiences help the
next generation of developers.
About the Technical Reviewer
Eldon Alameda
is a web developer who currently resides in the harsh climates of
Kansas. He works as a regional webmaster for the US National Weather
Service. Prior to this, he did development for a variety of companies
including local startups, advertising firms, Sprint PCS, and IBM. During
the 1990s, he also acquired a nice stack of worthless stock options from
working for dot-com companies.
© Jan Newmarch and Ronald Petty 2022
J. Newmarch, R. Petty, Network Programming with Go Language
https://doi.org/10.1007/978-1-4842-8095-9_1

1. Architectural Layers
Jan Newmarch1 and Ronald Petty2
(1) Oakleigh, VIC, Australia
(2) San Francisco, CA, USA

This chapter covers the major architectural features of distributed

systems. A distributed system is a collection of components interacting
over a network. You can’t build a system without some idea of what you
want to build. And you can’t build it if you don't know the environment
in which it will work. GUI programs are different than batch processing
programs; games programs are different than business programs; and
distributed programs are different than stand-alone programs. They
each have their approaches, their common patterns, the problems that
typically arise, and the solutions that are often used.
This chapter covers the high-level architectural aspects of
distributed systems. There are many ways of looking at such systems,
and many of these are dealt with. We begin with a layering model to
help us understand component boundaries, discuss network
implementation details, and consider how our components message
each other, wrapping up with error conditions and how to think about
them.

Protocol Layers
Distributed systems are hard. There are multiple computers involved,
which have to be connected in some way. Programs have to be written
to run on each computer in the system, and they all have to cooperate
to get a distributed task done.
 The common way to deal with complexity is to break it down into
smaller and simpler parts. These parts have their own structure, but
they also have defined means of communicating with other related
parts. In distributed systems, the parts are called protocol layers, and
they have clearly defined functions. They form a stack, with each layer
communicating with the layer above and the layer below. The
communication between layers is defined by protocols.
Network communications require protocols to cover high-level
application communication all the way down to wire communication
and the complexity handled by encapsulation in protocol layers.

ISO OSI Protocol

Although it was never properly implemented, the OSI (Open Systems
Interconnect) protocols have been a major influence in ways of talking
about and influencing distributed systems design. It is commonly given
as shown in Figure 1-1.

Figure 1-1 The Open Systems Interconnect protocol

OSI Layers
The function of each layer from bottom to top is as follows:
The Physical layer conveys the bit stream using electrical, optical, or
radio technologies.
The Data Link layer puts the information packets into network
frames for transmission across the Physical layer and back into
information packets.
The Network layer provides switching and routing technologies.
The Transport layer provides transparent transfer of data between
end systems and is responsible for end-to-end error recovery and
flow control.
The Session layer establishes, manages, and terminates connections
between applications.
The Presentation layer provides independence from differences in
data representation (e.g., encryption).
The Application layer supports application and end-user processes.
A layer in the OSI model often maps to a modern protocol; for
example, the IP from TCP/IP maps to the Network layer, also known as
layer 3 (Physical is layer 1). The Application layer, layer 7, maps to
HTTP. Some protocols like HTTPS seem to blend layers, 5 (Session) and
6 (Presentation). No model is perfect; alternatives exist to the OSI
model that maps closer to a given reality, such as the TCP/IP protocol
model.

TCP/IP Protocol
While the OSI model was being argued, debated, partly implemented,
and fought over, the DARPA Internet research project was busy building
the TCP/IP protocols. These have been immensely successful and have
led to The Internet (with capitals). This is a much simpler stack, as
shown in Figure 1-2.
Figure 1-2 The TCP/IP protocols

Some Alternative Protocols

Although it almost seems like it, the TCP/IP protocols are not the only
ones in existence and in the long run may not even be the most
successful. Wikipedia’s list of network protocols (see
https://en.wikipedia.org/wiki/List_of_network_prot
ocols_(OSI_model)) has a huge number more, at each of the OSI
ISO layers. Many of these are obsolete or of little use, but due to
advances in technology in all sorts of areas – such as the Internet in
Space and the Internet of Things – there will always be room for new
protocols.
The primary focus in this book is on OSI layers 3 and 4 (TCP/IP,
including UDP), but you should be aware that there are other ones.

Networking
A network is a communications system for connecting end systems
called hosts. The mechanisms of connection might be copper wire,
Ethernet, fiber optic, or wireless, but that won’t concern us here. A local
area network (LAN) connects computers that are close together,
typically belonging to a home, small organization, or part of a larger
organization.
A wide area network (WAN) connects computers across a larger
physical area, such as between cities. There are other types as well,
such as MANs (metropolitan area networks), PANs (personal area
networks), and even BANs (body area networks).
An internet is a connection of two or more distinct networks,
typically LANs or WANs. An intranet is an Internet with all networks
belonging to a single organization.
There are significant differences between an internet and an
intranet. Typically, an intranet will be under a single administrative
control, which will impose a single set of coherent policies. An internet,
on the other hand, will not be under the control of a single body, and
the controls exercised over different parts may not even be compatible.
A trivial example of such differences is that an intranet will often be
restricted to computers by a small number of vendors running a
standardized version of a particular operating system. On the other
hand, an internet will often have a smorgasbord of different computers
and operating systems.
The techniques of this book are applicable to internets. They are
also valid with intranets, but there you will also find specialized,
nonportable systems.
And then there is the “mother” of all internets: The Internet. This is
just a very, very large internet that connects us to Google, my computer
to your computer, and so on.

Gateways
A gateway is a generic term for an entity used to connect two or more
networks. A repeater operates at the Physical level and copies
information from one subnet to another. A bridge operates at the Data
Link layer level and copies frames between networks. A router operates
at the Network level and not only moves information between
networks but also decides on the route.
Host-Level Networking
On a single host, we have additional concerns when designing,
debugging, or deploying network-based software. Some of these items
include the following:
DNS (domain name system, i.e., human-friendly naming)
Firewalls (e.g., blocking inbound or outbound traffic)
Routing (e.g., figuring out which network to place a packet)
Host Identity management (e.g., IP address)
Performance controls (e.g., traffic shaping or retries)
Connection issues (e.g., missing network adapter, intramachine
process communication)
Through examples, we will see how a host misconfiguration might
manifest in our software.

Packet Encapsulation
The communication between layers in either the OSI or the TCP/IP
stacks is done by sending packets of data from one layer to the next and
then eventually across the network. Each layer has administrative
information that it has to keep about its own layer. It does this by
adding header information to the packet it receives from the layer
above, as the packet passes down. On the receiving side, these headers
are removed as the packet moves up.
For example, the TFTP (Trivial File Transfer Protocol) moves files
from one computer to another. It uses the UDP protocol on top of the IP
protocol, which may be sent over ethernet. This looks like the diagram
shown in Figure 1-3.
Figure 1-3 The TFTP (Trivial File Transfer Protocol)

Connection Models
In order for two computers to communicate, they must set up a path
whereby they can send at least one message in a session. There are two
major models for this:
Connection oriented
Connectionless

Connection Oriented
A single connection is established for the session. Two-way
communications flow along the connection. When the session is over,
the connection is broken. The analogy is to a phone conversation. An
example is TCP.

Connectionless
In a connectionless system, messages are sent independent of each
other. Ordinary mail is the analogy. Connectionless messages may
arrive out of order. Messages do not have an impact on each other. An
example is the IP protocol. UDP is a connectionless protocol above IP
and is often used as an alternative to TCP, as it is much lighter weight.
Connectionless is also known as unconnected or stateless.
Connection-oriented transports may be established on top of
connectionless ones – TCP over IP. Connectionless transports may be
established on top of connection-oriented ones – HTTP over TCP.
Messages over a connection-oriented transport protocol have some
kind of relation, for example, a sequence number used to keep order.
Having state allows for functionality and optimizations; it also has an
associated cost of storage and computing.
There can be variations on these. For example, a session might
enforce messages arriving but might not guarantee that they arrive in
the order sent. However, these two are the most common.
Connection models are not the only way a protocol can vary. One
often desired feature is reliability; this is where the protocol has logic to
fix some types of errors; for example, TCP resends a missing packet. It’s
pretty common to assume connection-oriented protocols are reliable;
this is not always the case (e.g., MPLS). Additional features of a network
protocol could include message boundary management, delivery
ordering, error checking, flow control, etc. These features can exist in
one protocol layer and not another, partly why there are so many
network protocol stacks.
Sometimes, these features are reworked throughout the protocol
stack. An example of this kind of feature rework is with HTTP/3. In
HTTP/2, reliability is provided using TCP at layer 4. In HTTP/3, TCP is
being replaced with UDP, which is not reliable. Instead, reliability will
be provided with another protocol known as QUIC. While QUIC is
considered a Transport layer, like TCP or UDP, it works on top of UDP.
As you can see, the layer model is not an exact science.

Communications Models
In a distributed system, there will be many components (i.e., processes)
running that have to communicate with each other. There are two
primary models for this, message passing and remote procedure calls.
In the context of networking, these models allow interprocess (and/or
thread) communication with intent to invoke behavior on the remote
process.

Message Passing
Some languages are built on the principle of message passing.
Concurrent languages (and tools) often use such a mechanism, and the
most well-known example is probably the UNIX pipeline. The UNIX
pipeline is a pipeline of bytes, but this is not an inherent limitation:
Microsoft’s PowerShell can send objects along its pipelines, and
concurrent languages such as Parlog can send arbitrary logic data
structures in messages between concurrent processes. Recent
languages such as Go have mechanisms for message passing (between
threads).
Message passing is a primitive mechanism for distributed systems.
Set up a connection and pump some data down it. At the other end,
figure out what the message was and respond to it, possibly sending
messages back. This is illustrated in Figure 1-4.
Figure 1-4 The message passing communications model
Event-driven systems act in a similar manner. At a low level, the
programming language node.js runs an event loop waiting for I/O
events, dispatching handlers for these events and responding. At a
higher level, most user interface systems use an event loop waiting for
user input, while in the networking world, Ajax uses the
XMLHttpRequest to send and receive requests.

Remote Procedure Call

In any system, there is a transfer of information and flow control from
one part of the system to another. In procedural languages, this may
consist of the procedure call, where information is placed on a call stack
and then control flow is transferred to another part of the program.
Even with procedure calls, there are variations. The code may be
statically linked so that control transfers from one part of the program’s
executable code to another part. Due to the increasing use of library
routines, it has become commonplace to have such code in shared
objects (.so) or dynamic link libraries (.dll), where control transfers to
an independent piece of code.
Libraries run in the same machine as the calling code. it is a simple
(conceptual) step to transfer control to a procedure running in a
different machine (i.e., remote library). The mechanics of this are not so
simple! However, this model of control has given rise to the remote
procedure call (RPC), which is discussed in much detail in a later
chapter. This is illustrated in Figure 1-5.

Figure 1-5 The remote procedure call communications model

There are many examples of this: some based on particular

programming languages such as the Go rpc package (discussed in
Chapter 13) or RPC systems covering multiple languages such as SOAP
and Google’s gRPC.
It may not be clear how message passing and RPC differ. At one
level, they both are involved with invoking behavior “somewhere else.”
Generally speaking, RPC tends to be less abstract (i.e., looks and feels
like regular procedure calls) compared to message passing where we
could be calling remote queueing system. Under the hood though, RPC
will be passing messages.

Distributed Computing Models

At the highest level, we could consider the equivalence or the
nonequivalence of components of a distributed system. The most
common occurrence is an asymmetric one: a client sends requests to a
server, and the server responds. This is a client-server system.
If both components are equivalent, both able to initiate and to
respond to messages, then we have a peer-to-peer system. Note that this
is a logical classification: one peer may be a 16,000-core
supercomputer; the other might be a mobile phone. But if both can act
similarly, then they are peers.
These are illustrated in Figure 1-6.

Figure 1-6 Client-server vs. peer-to-peer systems

An example of a client-server is a browser talking to a web server.

An example of a peer-to-peer system could be database system where
data is replicated and available on both peers.
Combinations of these systems result in what is known as multitier
architectures, where three-tier architecture is one of the most common
(i.e., presentation -> application -> data or browser -> web server ->
database).

Client-Server System
Another view of a client-server system is shown in Figure 1-7.

Figure 1-7 The client-server system

This view may be held by a developer who needs to know the

components of a system. It is also the view that may be held by a user: a
user of a browser knows it is running on their system but is
communicating with servers elsewhere.
The prior diagram looks similar to the OSI model we discussed
earlier. Layers in Figure 1-7 are also optional; for example, we can have
both the client and server process on a single piece of hardware. Being
located on the same machine means we can potentially remove some
layers of the OSI model including layer 1 (Physical), layer 2 (Data Link),
and layer 3 (Network). We say potentially because these layers still may
be desired for various reasons including tooling homogeneity or
security.

Client-Server Application
Some applications may be seamlessly distributed, with the user
unaware that it is distributed. Users will see their view of the system, as
shown in Figure 1-8.
Figure 1-8 The user’s view of the system
In order to function, both components must be installed, how
seamless this complexity will vary by application (and its usage).

Server Distribution
A client-server system need not be simple. The basic model is a single
client, single server system, as shown in Figure 1-9.

Figure 1-9 The single-client, single-server system

However, you can also have multiple clients, single server, as

illustrated in Figure 1-10.

Figure 1-10 The multiple-clients, single-server system

Discovering Diverse Content Through
Random Scribd Documents
Lincoln, seeking an occupation that would afford him a better living
than odd jobs, considered becoming a blacksmith. For a time his
strong arms grappled with the chore, but he preferred lighter work
which allowed him more time for studying. He also had thoughts of
becoming a merchant.
62

The limbs of the great oak tree still cast their shadows across the
Lincoln-Berry store. In fair weather, when housewives were busy
and sales were restricted to an occasional pound of sugar or a
piece of beeswax, Lincoln, barefoot, lay stretched out under the
oak tree, lost in a book.

64
The Rutledge Tavern, where Lincoln courted Ann Rutledge, stood
across the road from the Lincoln-Berry store. While waiting on a
customer, or studying under the oak tree, he often paused to watch
her as she moved about the yard of the tavern.
A burning candle in the tavern window welcomed whatever
wayfarer might be seeking food and lodging.

65
The tavern was a pleasant and comfortable place. Every day
brought new guests to the dining room. For a time Lincoln lived at
the tavern; his wit and tall tales often made him the center of
interest.
66
While residing at the tavern, Lincoln climbed the rungs of a well-
worn ladder to the loft, where he shared a bed with E. Y. Ellis, who
says that Lincoln’s wit and stories often kept the other male guests
in an uproar until late at night.
67
The west room of the tavern accommodated the Rutledge family
and now and then an overnight lady guest.
68
On Sunday evenings the Rutledge family and friends gathered
before the fireplace to listen to a sermon and to sing hymns.
Lincoln stood near Ann and turned the pages of her Missouri
Harmony Song Book.
69
The betrothal of Ann Rutledge and Lincoln ended with her untimely
death. Ann’s brother said: “The effect upon Mr. Lincoln’s mind was
terrible. He became plunged in despair, and many of his friends
feared reason would desert her throne. His extraordinary emotions
were regarded as strong evidence of the existence of the tenderest
relations between himself and the deceased.”
70
Lincoln, the ardent student, could be found pursuing his studies in
the most unusual places. Squire Godbey, seeing him stretched out
on a pile of wood, inquired: “What are you reading Abe?” Lincoln
replied: “I am not reading. I am studying Law.” “Law? Good God
A’mighty!” exclaimed the surprised squire as he walked away.
71
The little subscription schoolhouse stands a half mile south of the
village near Purkapile “crick.” Schoolmaster Mentor Graham was a
constant stimulus to Lincoln and always ready to help and
encourage him. After the day’s routine had ended Lincoln often
came to the school so that the master might evaluate his progress.
72
In 1834, Lincoln’s quest for knowledge and esteem was rewarded.
The citizens of Sangamon County sent the novice lawmaker to the
State Capitol at Vandalia, to take his seat in the Ninth General
Assembly of the Legislature of Illinois.
73
In the Assembly, Lincoln said little, but observed closely and
learned much. He was among men of affairs, education and
political experience. He became floor leader of the Whigs and an
esteemed member of a political group known as the “Long Nine”
who were successful in having the State Capitol moved from
Vandalia to Springfield.
74
In March of 1837, after having been admitted to the bar in Illinois,
Lincoln moved from New Salem to Springfield. For the next twenty-
five years the first State Capitol Building in Springfield became the
center of his many activities.
75
The Postville Courthouse was on the “Old Eighth Circuit.” In
Lincoln’s day judges and lawyers rode horseback from one county
courthouse to another, so as to make a living by representing the
litigants in the suits to be heard. This was known as “riding the
circuit.”
76
The Mount Pulaski Courthouse hasn’t changed much since Lincoln
practiced law here more than a hundred years ago.
 77

In the court and jury room Lincoln argued cases before such
distinguished judges as David Davis, who became a Justice of the
United States Supreme Court.