WWDC, in case you aren’t familiar with it, is Apple’s Worldwide Developer Conference, which they hold annually. This year, Apple announced several groundbreaking releases, and while not fully focused on consumers, these releases will help developers and professionals create more immersive, intuitive, and fun experiences for their users. Nonetheless, this was likely Apple’s most jam-packed event thus far.

This article will give you a quick rundown of the major releases in this year’s WWDC conference and help you get a sense of what happened — even if you didn’t have the time to watch the keynote. In case you’re interested in going over it yourself, however, you can watch the full presentation as well as the various sessions throughout the week on Apple’s website.

Table of Contents

Follow the links to jump to each section.

• tvOS
• iOS
• iPadOS
• watchOS
• macOS Catalina
• Mac Pro
• Pro Display XDR
• Developer Tools

tvOS

The conference began with tvOS after Tim Cook made some opening remarks. Despite minor user interface changes, not much has changed in the newest version of tvOS. Instead, Apple focused on their services, which they launched during the Spring Special Event earlier this year.

Apple TV+

This service is to provide a Netflix-style streaming service with only Apple’s original content as a part of the service. During the keynote, they showcased one of their original Apple TV+ shows, in which the story of the first moon landing on the moon is revised so that the Soviet Union is the first as opposed to the United States.

Trailer Clip from “For All Mankind”

New Wallpapers

The latest wallpapers on Apple TV are stunning — they keep you immersed and wondering how and when each of the videos were recorded. Last year, Apple partnered with the International Space Station to capture high resolution footage from outer space, but this year, they’re delving into the ocean to get a submarine-style look at underwater life.

Announcing Submarine Wallpapers for tvOS

iOS

As with every WWDC, we have our latest version of iOS — and they didn’t skip the number thirteen for those with triskaidekaphobia. However, this release did not cover the iPad, and is only available for iPhone—more on that later.

Dark Mode

The most popular feature, by far, was Dark Mode. This long-awaited setting allows most apps to switch into a beautiful state, in which menus, bars, and fields become less apparent. This allows users to have a more immersive content experience, while giving the appearance that less of their screen real estate is being wasted.

Dark Mode on iOS 13

Privacy and Data

While Apple’s always finding new ways to protect their customers’ data, this year, they’re allowing developers to use a Sign in with Apple button to further protect data. In addition, they’re asking users for nearly everything to ensure privacy, whether it’s location services, notifications, or microphone access.

The “Sign in with Apple” Button

Memoji

Memojis have always been a fun, whimsical way to convey one’s emotions over text, but Apple’s bringing more life than ever to these. You can now add makeup to them, and also set them as a profile picture for all of your iMessage contacts to see.

Patrick Starrr and Desi Perkins’ Memojis

Maps

After driving around for millions of miles, Apple’s managed to get a high resolution view with Look Around, a feature that allows users to pan through a map as if they were biking or driving through it. While not completed, Apple says they’re working hard to help get this feature to other states and countries as well.

Craig Federighi Announcing Apple Maps Updates

iPadOS

While still sharing its underlying DNA with iOS, iPadOS gives the iPad new functionality, utilizing some of its more unique hardware capabilities. This allows it to become closer to Apple’s dream of a PC-replacement and less of a tablet. While not fully a laptop just yet, the iPad is now closer than ever.

Desktop-Class Browsing

Among the bigger changes, Apple announced that users can now use Safari for the desktop version of websites. They used Google Docs and Wordpress as examples to show how you can take advantage of this feature and not be limited by mobile sites or apps.

Google Docs Website on iPadOS

PencilKit

The Apple Pencil has been improved greatly, with latency reduced from 20ms to just 9ms. In addition, with a wide array of system tools for the pencil, developers now have the option to add their own if they wish to do so.

Apple Pencil on Photoshop

Sidecar

Without any additional tools, you can now use the iPad as a secondary display for your Mac. You can also use it as a drawing tablet, too, using the Apple Pencil on professional apps on your Mac such as Photoshop, Illustrator, and Final Cut Pro.

Sidecar with Affinity Photo on iPadOS

watchOS

The Apple Watch has become a staple for many, allowing them to be more active throughout the day, and saving many from life-threatening situations throughout the years of its existence. This year, watchOS makes it even more powerful.

Standalone Apps

Previously, apps for the Apple Watch needed to be tethered to an iPhone companion app, but now, the Apple Watch is getting its own App Store, which causes a reduction in app download size, and gives it the independence the watch needs to be useful for many applications.

Independence for watchOS Apps

New Watch Faces

Who doesn’t want new watch faces? Apple recently updated the list with some new ones which both improve the appearance and functionality of the watch, and these can be used for anyone running the latest version of watchOS.

New Watch Faces on watchOS

macOS Catalina

Becoming closer to iPadOS, macOS Catalina has several new features, most of which are centered on developers — and again — helping them make better, more functional apps.

Project Catalyst

While it was foreshadowed during last year’s WWDC, Apple officially announced Project Catalyst this year. Due to the underlying similarities between macOS and iPadOS, this framework will allow developers to directly port their iPad apps as native Mac apps. It will also allow developers to create a single app across all of Apple’s platforms by just checking a box.

Project Catalyst on macOS

No More iTunes

After eighteen years of having launched iTunes, it is now being discontinued — however, its core functionality still remains. In Finder, you’ll find (no pun intended) your iOS device syncing tools, and in two new apps, Music and Podcasts, you’ll be able to access your music.

Music, Podcasts, and Apple TV

Screen Time

Screen time was a very useful addition to iOS last year, allowing users to keep tabs on how much they were using their devices. But — as a developer, I find myself using my Mac way more than my iOS devices, and therefore, having this feature on the Mac is great, because it allows for the same awareness for the computer. In addition, Apple has added some great new parental control features, which allow parents to limit the amount of time their kids spend on their computers, too.

Screen Time on macOS Catalina

Mac Pro

Right in line with macOS, Apple replaced their five-year-old “trashcan” Mac Pro and launched a powerful new model, which is the size of a traditional desktop. It allows for customization, and is targeted at enterprise-level professionals.

Design

The Mac Pro is no longer small enough to fit on your desk, but in turn, it comes in a gorgeous aluminum frame with a striking ventilation pattern. Known as the “cheese grater” by the people of the internet, it’s something you’re sure not to miss.

Lattice Ventilation on the New Mac Pro

Performance

The computer itself is a powerhouse. By lifting the aluminum enclosure, you get access to the Mac’s internals from all angles, allowing you to take advantage of the 8 PCle slots, and spec it up to 28 cores of processing power, 1.5 TB of memory, and use the best GPU on the planet (not by Nvidia).

Mac Pro Connected to Professional Rig

Pro Display XDR

As a “companion” for the Mac Pro, you’ll also be able to purchase the Pro Display XDR, which, again, is targeted at commercial-level users. This display is stunning on the specs sheet, and is an uncompromising companion when used with the Mac Pro.

Design

Similar to the Mac Pro, this display shares the lattice-like structure in the back to cool the amazing display. As usual, Apple has managed to cram the power of a top-of-the line $40,000 display, which weighs several times the amount of the Pro Display XDR, into a slim, bezel-less form factor.

Pro Display XDR from Multiple Angles

Performance

The brightness of this display is paramount — it can run continuously with a sustained brightness of 1000 nits, and with content which supports it, it peaks at 1600 nits. For a full dynamic range of colors, the display also offers a record 1000000:1 contrast ratio and supports a P3 wide color gamut.

Pro Display XDR and its Wide Color Gamut

Mounting

Apple doesn’t sell this stand with any mount, but for most professionals, they’ll already have a VESA mount to use with it. But if not, they can opt for the Pro Stand, which allows for seemingly weightless adjustments due to its over-engineered counterbalancing mechanism.

The Pro Mount for the Pro Display XDR

Developer Tools

After all, WWDC is aimed at “developers,” so to honor this, they’ve made huge changes to their developer tools, APIs, and their IDE. Some of these include Core ML, ARKit, and SwiftUI.

Core ML 3

Having been their main machine learning framework for several years, Apple continues to make important updates to it. This year, they’ve introduced support for activity classification, image segmentation, and sound classification, as well as extended support for NLP tasks. You can also now train these models with a dedicated Create ML app, as long as you’re running macOS Catalina.

Among one of the bigger changes is the ability to have custom models on users’ devices without needing a server-side database, which means that the model will adapt according to user patterns and be unique for each person’s device. This allows personalized results to be shown to the user, while still maintaining the privacy of local data processing.

Create ML App for Developers on macOS

ARKit

Augmented reality works great on Apple’s platforms. And this year, it works even better. For those without any formal 3D design experience, Apple has announced Reality Composer and RealityKit, two tools which go hand-in-hand to allow developers to create augmented reality experiences with ease. In code, RealityKit provides — as the name suggests — a way for developers to apply effects to improve the realism of their apps.

People have always been the center of ARKit, but now, it’s more apparent than ever. Three major features in this year’s release of ARKit are people occlusion, motion capture, and the ability to track multiple faces at once. This allows developers to create very immersive experiences, since augmented reality content can now appear to move behind people, and the ability to map people’s motions to a wireframe skeleton allows for much more flexibility. Previously, face detection was limited to one face, but now, developers can detect multiple faces using the front and rear cameras simultaneously.

Reality Kit for Easy Augmented Reality Experiences

SwiftUI

With all of their other great releases, Apple also launched a new framework for responsive and data-driven user interface design. This framework allows developers to use a new Swift-based syntax to layout their apps and have them work natively across multiple device sizes, layouts, and types. Along with this, they’ve added the ability to “live preview” the app without needing to run it each time you make a change.

SwiftUI Announced on Stage

In conclusion, this year’s WWDC was packed with new features, products, and developer tools, and hopefully, you were able to get a glimpse of it through this article. While you’re here, stay tuned for some great new tutorials on the latest frameworks, and get ahead of the crowd by taking use of them before they’re released to the public in the fall.

Be sure to share this tutorial on social media, and follow me on Twitter.

Vardhan Agrawal (@vhanagwal) | Twitter
_The latest Tweets from Vardhan Agrawal (@vhanagwal). Completely self-taught #ios developer, #instructor, and human…_twitter.com

Today, let’s take a look at “Program Design in the Unix Environment” published in 1983 by Pike and Kernighan.

The paper opens by listing why Unix has been successful, and then comments on the Unix philosophy and its benefits. It does so by looking at examples where programs diverged from the Unix philosophy and discussing the resulting trade offs

The reasons for Unix’s success:

1. Portability: the kernel & applications were written in C, so they could be moved from system to system without being re-written in the assembly language particular to that system.
2. The same OS ran on different hardware, so the users were already familiar and didn’t have to relearn when new hardware was released.
3. The vendors could ship the same software with each machine despite changes in hardware.
4. The system was not too big and was easy to modify since everything was written in C.
5. It provided a new philosophy based on the use of general purpose tools. They did one thing well and could be combined to do a particular task, instead of creating giant monolithic tools that served only one purpose.

The paper argues that the use and design of tools is closely related, and how they fit together is the main subject of this essay.

The paper then dives into cat (the Unix command line utility for concatenating and printing files). It copies its input to its output. The input is usually a sequence of one or more files or the standard input. The output is a file or the standard output.

The main purpose of cat was to act as a utility to concatenate files. It can be combined with the pipe (|) operator to further enhance and extend its utility through output redirection.

Other systems, on the other hand, try to dump a bunch of related functionality into a single command which is against the Unix philosophy. It also creates a lock-in of functionality that might be useful to other programs.

Advantages of the Unix approach:

1. The shell and the programs it can invoke provide uniform access to system facilities. Eg: the filename arguments are expanded by the shell in a similar fashion for each command. Because of pipes, we don’t need every command to deal with pre- and post- processing of input.
2. Growth is easy when functions are well-separated.

Example: the `(backtic) operator was added to convert the output of one program into the input of another without requiring changes in any other program as it is interpreted by the shell. All programs the shell invokes acquire this feature automatically. If each program that required this feature interpreted it, it’d be very hard to enforce uniformity and carry out further experimentation, as each new idea would affect all the programs that would want to use it.

However, in future versions of cat, many new options were introduced (such as printing line numbers and non-printable characters).

The authors argue that instead of adding those options to cat itself, either existing programs should’ve been used or new programs should’ve been created. For example, line number functionality could’ve been provided by using pr. However, there was no program which allowed printing of non-printable characters which warranted the creation of a new one.

Such a modification confuses what cat’s job is  concatenating files  with
what it happens to do in a common special case  showing a file on the terminal. A UNIX program should do one thing well, and leave unrelated tasks to other programs. cat’s job is to collect the data in files. Programs that collect data shouldn’t change the data; cat therefore shouldn’t transform its input.

Whenever we split something into multiple programs, we sacrifice some efficiency. But since cat is usually used without any options, it makes sense to have the most common cases be the most efficient.

Separate programs are not always better than wider options; which is better depends on the problem. Whenever one needs a way to perform a new function, one faces the choice of whether to add a new option or write a new program (assuming that none of the programmable tools will do the job conveniently). The
guiding principle for making the choice should be that each program does one thing. Options are appropriately added to a program that already has the right functionality. If there is no such program, then a new program is called for. In that case, the usual criteria for program design should be used: the program should be as general as possible, its default behavior should match the most common usage, and it should cooperate with other programs.

Let’s consider another issue: dealing with fast terminal lines. How do we deal with output from cat scrolling off the top of the screen?

There are two approaches:

1. Tell each command about terminal properties so it does the right thing
2. Write a command that handles only terminals without modifying other programs

Let’s consider examples of both approaches: lsc and ls which prints out the list of files in a directory.

lsc varies its output depending on the input. It displays the list in a columnar fashion across the screen so that the o/p fits if it’s outputting to the terminal. ls displays everything in a single column.

By retaining single column output to files or pipes, lsc ensures compatibility with programs like grep or wc that expect things to be printed one per line. This ad-hoc adjustment of the output format depending on the destination is not only distasteful, it is unique  no standard UNIX command has this property.

The authors argue that the columnation facility is useful in general and shouldn’t be locked away in just lsc , making it inaccessible to other programs. They advocate for a different program whose primary job is columnation.

Similar reasoning suggests a solution for the general problem of data flowing off screens (columnated or not): a separate program to take any input and print it a screen at a time. Such programs are by now widely available, under names like pg and more. This solution affects no other programs, but can be used with all of them. As usual, once the basic feature is right, the program can be enhanced with options…

Based on the previous example, the authors also talk about different cases where some functionality is locked away in a specific program (like input history in the terminal) which would be better off as a central service. All interactive programs could benefit from it.

They conclude with how augmenting existing commands with features/options is not desirable in Unix, it goes against its basic philosophy: make a program do one thing well. Several such programs can be composed to accomplish a more complex task.

The key to problem solving on the UNIX system is to identify the right primitive operations and to put them at the right place. UNIX programs tend to solve general problems rather than special cases. In a very loose sense, the programs are orthogonal, spanning the space of jobs to be done (although with a fair
amount of overlap for reasons of history, convenience or efficiency). Functions are placed where they will do the most good: there shouldn’t be a pager in every program that produces output any more than there should be filename pattern matching in every program that uses filenames.

One thing that UNIX does not need is more features. It is successful in part because it has a small number of good ideas that work well together. Merely adding features does not make it easier for users to do things  it just makes the manual thicker. The right solution in the right place is always more effective
than haphazard hacking.

Let’s try to break down the paper “Building On Quicksand” published by Pat Helland and David Campbell in 2009. All pull quotes are from the paper.

The paper focuses on the design of large, fault-tolerant, replicated distributed systems. It also discusses its evolving based on changing requirements over time. It starts off by stating “Reliable systems have always been built out of unreliable components”.

As the granularity of the unreliable component grows (from a mirrored disk to a system to a data center), the latency to communicate with a backup becomes unpalatable. This leads to a more relaxed model for fault tolerance. The primary system will acknowledge the work request and its actions without waiting to ensure that the backup is notified of the work. This improves the responsiveness of the system because the user is not delayed behind a slow interaction with the backup.

Fault-tolerant systems can be made of many components. Their goal is keep functioning when one of those components fail. We don’t consider Byzantinefailures in this discussion. Instead, the fail fast model where either a component works correctly or it fails.

The paper goes on to compare two versions of the Tandem NonStop system. One that used synchronous checkpointing and one that used asynchronous checkpointing. Refer section 3 of the paper for all the details. I’d like to touch upon the difference between the two checkpointing strategies.

• Synchronous checkpointing: in this case, with every write to the primary, state needed to be sent to the backup. Only after the backup acknowledged the write, did the primary send a response to the client who issued the write request. This ensured that when the primary fails, the backup can take over without losing any work.
• Asynchronous checkpointing: in this strategy, the primary acknowledges and commits the write. This is done as soon as it processes it without waiting for a reply from the backup. This technique has improved latency but also poses other challenges addressed later.

Log Shipping

A classic database system has a process that reads the log and ships it to a backup data-center. The normal implementation of this mechanism commits transactions at the primary system (acknowledging the user’s commit request) and asynchronously ships the log. The backup database replays the log, constantly playing catch-up.

The mechanism described above is termed as log shipping. The main problem this poses is that when the primary fails and the back up takes over, some recent transactions might be lost.

This inherently opens up a window in which the work is acknowledged to the client but it has not yet been shipped to the backup. A failure of the primary during this window will lock the work inside the primary for an unknown period of time. The backup will move ahead without knowledge of the locked-up work.

The introduction of asynchrony into the system has an advantage in latency, response time and performance. However, it makes the system more prone to the possibility of losing work when the primary fails. There are two ways to deal with this:

1. Discard the work locked in the primary when it fails. Whether a system can do that or not depends on the requirements and business rules.
2. Have a recovery mechanism to sync the primary with backups when it comes back up and retries lost work. This is possible only if the operations can be retried in an idempotent way and the out-of-order retries are possible.

The system loses the notion of what the authors call “an authoritative truth”. Nobody knows the accurate state of the system at any given point in time if the work is locked in an unavailable backup or primary.

The authors conclude that business rules in a system with asynchronous checkpointing are probabilistic.

If a primary uses asynchronous checkpointing and applies a business rule on the incoming work, it is necessarily a probabilistic rule. The primary, despite its best intentions, cannot know it will be alive to enforce the business rules.

When the backup system that participates in the enforcement of these business rules is asynchronously tied to the primary, the enforcement of these rules inevitably becomes probabilistic!

The authors state that commutative operations, operations that can be reordered, can be executed independently, as long as the operation preserves business rules. However, this is hard to do with storage systems because the write operation isn’t commutative.

Another consideration is that work of a single operation is idempotent. For example, executing the operation any number of time should result in the same state of the system.

To ensure this, applications typically assign a unique number or ID to the work. This is assigned at the ingress to the system (i.e. whichever replica first handles the work). As the work request rattles around the network, it is easy for a replica to detect that it has already seen that operation and, hence, not do the work twice.

The authors suggest that different operations within a system provide different consistency guarantees. Yet, this depends on the business requirements. Some operations can choose classic consistency over availability and vice versa.

Next, the authors argue that as soon there is no notion of authoritative truth in a system. All computing boils down to three things: memories, guesses, and apologies.

1. Memories: you can only hope that your replica remembers what it has already seen.
2. Guesses: Due to only partial knowledge being available, the replicas take actions based on local state and may be wrong. “In any system which allows a degradation of the absolute truth, any action is, at best, a guess.” Any action in such a system has a high probability of being successful, but it’s still a guess.
3. Apologies: Mistakes are inevitable. Hence, every business needs to have an apology mechanism in place either through human intervention or by automating it.

The paper next discusses the topic of eventual consistency. The authors do this by taking the Amazon shopping cart built using Dynamo & a system for clearing checks as examples. A single replica identifies and processes the work coming into these systems. It flows to other replicas as and when connectivity permits. The requests coming into these systems are commutative (reorderable). They can be processed at different replicas in different orders.

Storage systems alone cannot provide the commutativity we need to create robust systems that function with asynchronous checkpointing. We need the business operations to reorder. Amazon’s Dynamo does not do this by itself. The shopping cart application on top of the Dynamo storage system is responsible for the semantics of eventual consistency and commutativity. The authors think it is time for us to move past the examination of eventual consistency in terms of updates and storage systems. The real action comes when examining application based operation semantics.

Next, they discuss two strategies for allocating resources in replicas that might not be able to communicate with each other:

1. Over-provisioning: the resources are partitioned between replicas. Each has a fixed subset of resources they can allocate. No replica can allocate a resource that’s not actually available.
2. Over-booking: the resources can be individually allocated without ensuring strict partitioning. This may lead to the replicas allocating a resource that’s not available, promising something they can’t deliver.

The paper talks also about something termed as the “seat reservation pattern”. This is a compromise between over-provisioning and over-booking:

Anyone who has purchased tickets online will recognize the “Seat Reservation” pattern where you can identify potential seats and then you have a bounded period of time, (typically minutes), to complete the transaction. If the transaction is not successfully concluded within the time period, the seats are once again marked as “available”.

ACID 2.0

The classic definition of ACID stands for “Atomic, Consistent, Isolated, and Durable”. Its goal is to make the application think that there is a single computer which isn’t doing anything else when the transaction is being processed. The authors talk about a new definition for ACID. which stands for Associative, Commutative, Idempotent, and Distributed.

The goal for ACID2.0 is to succeed if the pieces of the work happen: At least once, anywhere in the system, in any order. This defines a new KIND of consistency. The individual steps happen at one or more system. The application is explicitly tolerant of work happening out of order. It is tolerant of the work happening more than once per machine, too.

Going by the classic definition of ACID, a linear history is a basis for fault tolerance. If we want to achieve the same guarantees in a distributed system, it’ll require concurrency control mechanisms which “tend to be fragile”.

When the application is constrained to the additional requirements of commutativity and associativity, the world gets a LOT easier. No longer must the state be checkpointed across failure units in a synchronous fashion. Instead, it is possible to be very lazy about the sharing of information. This opens up offline, slow links, low-quality datacenters, and more.

In conclusion:

We have attempted to describe the patterns in use by many applications today as they cope with failures in widely distributed systems. It is the reorderability of work and repeatability of work that is essential to allowing successful application execution on top of the chaos of a distributed world in which systems come and go when they feel like it.

P.S. — If you made it this far and would like to receive a mail whenever I publish one of these posts, sign up here.

This article presents a summary of the paper “Harvest, Yield, and Scalable Tolerant Systems” published by Eric Brewer & Amando Fox in 1999. All unattributed quotes are from this paper.

The paper deals with the trade-offs between consistency and availability (CAP) for large systems. It’s very easy to point to CAP and assert that no system can have consistency and availability.

But, there is a catch. CAP has been misunderstood in a variety of ways. As Coda Hale explains in his excellent blog post “You Can’t Sacrifice Partition Tolerance”:

Of the CAP theorem’s Consistency, Availability, and Partition Tolerance, Partition Tolerance is mandatory in distributed systems. You cannot not choose it. Instead of CAP, you should think about your availability in terms of yield (percent of requests answered successfully) and harvest (percent of required data actually included in the responses) and which of these two your system will sacrifice when failures happen.

The paper focuses on increasing the availability of large scale systems by fault toleration, containment and isolation:

We assume that clients make queries to servers, in which case there are at least two metrics for correct behavior: yield, which is the probability of completing a request, and harvest, which measures the fraction of the data reflected in the response, i.e. the completeness of the answer to the query.

The two metrics, harvest and yield can be summarized as follows:

• Harvest: data in response/total data
  For example: If one of the nodes is down in a 100 node cluster, the harvest is 99% for the duration of the fault.
• Yield: requests completed with success/total number of requests
  Note: Yield is different from uptime. Yield deals with the number of requests, not only the time the system wasn’t able to respond to requests.

The paper argues that there are certain systems which require perfect responses to queries every single time. Also, there are systems that can tolerate imperfect answers once in a while.

To increase the overall availability of our systems, we need to carefully think through the required consistency and availability guarantees it needs to provide.

Trading Harvest for Yield — Probabilistic Availability

Nearly all systems are probabilistic whether they realize it or not. In particular, any system that is 100% available under single faults is probabilistically available overall (since there is a non-zero probability of multiple failures)

The paper talks about understanding the probabilistic nature of availability. This helps in understanding and limiting the impact of faults by making decisions about what needs to be available and what kind of faults the system can deal with.

They outline the linear degradation of harvest in case of multiple node faults. The harvest is directly proportional to the number of nodes that are functioning correctly. Therefore, it decreases/increases linearly.

Two strategies are suggested for increasing the yield:

1. Random distribution of data on the nodes
   If one of the nodes goes down, the average-case and worst-case fault behavior doesn’t change. Yet if the distribution isn’t random, then depending on the type of data, the impact of a fault may vary.
   For example, if only one of the nodes stored information related to a user’s account balance goes down, the entire banking system will not be able to work.
2. Replicating the most important data
   This reduces the impact in case one of the nodes containing a subset of high-priority data goes down.
   It also improves harvest.

Another notable observation made in the paper is that it is possible to replicate all your data. It doesn’t do a lot to improve your harvest/yield, but it increases the cost of operation substantially. This is because the internet works based on best-in-effort protocols which can never guarantee 100% harvest/yield.

Application Decomposition and Orthogonal Mechanisms

The second strategy focuses on the benefits of orthogonal system design.

It starts out by stating that large systems are composed of subsystems which cannot tolerate failures. But they fail in a way that allows the entire system to continue functioning with some impact on utility.

The actual benefit is the ability to provision each subsystem’s state management separately, providing strong consistency or persistent state only for the subsystems that need it, not for the entire application. The savings can be significant if only a few small subsystems require the extra complexity.

The paper states that orthogonal components are completely independent of each other. They have no run time interface to other components, unless there is a configuration interface. This allows each individual component to fail independently and minimizes its impact on the overall system.

Composition of orthogonal subsystems shifts the burden of checking for possibly harmful interactions from runtime to compile time, and deployment of orthogonal guard mechanisms improves robustness for the runtime interactions that do occur, by providing improved fault containment.

The goal of this paper was to motivate research in the field of designing fault-tolerant and highly available large scale systems.

Also, to think carefully about the consistency and availability guarantees the application needs to provide. As well as the trade offs it is capable of making in terms of harvest against yield.

If you enjoyed this paper, please hit the clap button so more people see it. Thank you.

P.S. — If you made it this far and would like to receive a mail whenever I publish one of these posts, sign up here.

This article distills the content presented in the paper “Some Constraints and Trade-offs In The Design of Network Communications” published in 1975 by E. A. Akkoyunlu et al.

The paper focuses on the inclusion of Interprocess Communication (IPC) primitives and the consequences of doing so. It explores, in particular, the time-out and the insertion property feature described in detail below with respect to distributed systems of sequential processes without system buffering and interrupts.

It also touches upon the two generals problem which states that it’s impossible for two processes to agree on a decision over an unreliable network.

Introduction:

The design of an Interprocess Communication Mechanism (IPCM) can be described by stating the behavior of the system and the required services. The features to be included in the IPCM are very critical as they might be interdependent, hence the design process should begin with a detailed spec. This involves thorough understanding of the consequences of each decision.

The major aim of the paper is to point out the interdependence of the features to be incorporated in the system.

The paper states that at times the incompatibility between features is visible from the start. Yet, sometimes two features which seem completely unrelated end up affecting each other significantly. If the trade-offs involved aren’t explored at the beginning, it might not be possible to include desirable features. Trying to accommodate conflicting features results in messy code at the cost of elegance.

Intermediate Processes:

Let’s suppose a system doesn’t allow indirect communication between processes that cannot establish a connection. The users just care about the logical sender and receiver of the messages: they don’t care what path the messages take or how many processes they travel through to reach their final destination. In such a situation, intermediate processes come to our rescue. They’re not a part of the IPCM but are inserted between two processes that can’t communicate directly through a directory or broker process when the connection is set up. They’re the only ones aware of the indirect nature of communication between the processes.

Centralized vs. Distributed Systems:

Centralized Communication Facility

1. Has a single agent which is able to maintain all state information related to the communication happening in the system
2. The agent can also change the state of the system in a well-defined manner

For example, if we consider the IPCM to be the centralized agent, it’ll be responsible for matching the SEND and RECEIVE requests of two processes, transferring data between their buffers and relaying appropriate status to both.

Distributed Communication Facility

1. No single agent has the complete state information at any time
2. The IPCM is made of several individual components which coordinate, exchange and work with parts of state information they possess.
3. A global change can take a considerable amount of time
4. If one of the components crashes, the activity of other components still interests us

Case 1:

In Figure 1, P1 and P2 are the two communicating processes on different machines over a network with their own IPCMs and P is the interface which enables this, with parts that lie on both machines. P handles the details of the network lines.

If one machine or a communication link crashes, we want the surviving IPCM’s to continue their operation. At least one component should detect a failure and be able to communicate. (In the case of a communication link failure, both ends must know.)

Case 2:

Distributed communication can also happen on the same machine given that there are one or more intermediate processes taking part in the system. In that case, P, P1 and P2 will be processes on the same system with identical IPCMs. P is an intermediate processes which facilitates the communication between P1 and P2.

Transactions between P1 and P2 consist of two steps: P1 to P and P to P2. Normally, the status returned to P1 would reflect the result of the P1 to P transfer, but P1 is interested in the status of the over all transaction from P1 to P2.

One way to deal with this is a delayed status return. The status isn’t sent to the sender immediately after the transaction occurs but only when the sender issues a SEND STATUS primitive. In the example above, after receiving the message from P1, P further sends it to P2, doesn’t send any status to P1 and waits to receive a status from P2. When it receives the appropriate status from P2, it relays it to P1 using the SEND STATUS primitive.

Special Cases of Distributed Facility

This section starts out by stating some facts and reasoning around them.

FACT 0: A perfectly reliable distributed system can be made to behave as a centralized system.

Theoretically, this is possible if:

1. The state of different components of the system is known at any given time
2. After every transaction, the status is relayed properly between the processes through their IPCMs using reliable communication.

However, this isn’t possible in practice because we don’t have a perfect reliable network. Hence, the more realistic version of the above fact is:

FACT I: A distributed IPCM can be made to simulate a centralized system provided that:

1. The overall system remains connected at all times, and

2. When a communication link fails, the component IPCM’s that are connected to it know about it, and

3. The mean time between two consecutive failures is large compared to the mean transaction time across the network.

The paper states that if the above conditions are met, we can establish communication links that are reliable enough to simulate a centralized systems because:

1. There is always a path from the sender to the receiver
2. Only one copy of an undelivered message will be retained by the system in case of a failure due to link failure detection. Hence a message cannot be lost if undelivered and will be removed from the system when delivered.
3. A routing strategy and a bound on the failure rate ensures that a message moving around in a subset of nodes will eventually get out in finite time if the target node isn’t present in the subset.

The cases described above are special cases because they make a lot of assumptions, use inefficient algorithms and don’t take into account network partitions leading to disconnected components.

Status in Distributed Systems

Complete Status

A complete status is one that relays the final outcome of the message, such as whether it reached its destination.

FACT 2: In an arbitrary distributed facility, it is impossible to provide complete status.

Case 1:

Assume that a system is partitioned into two disjoint networks, leaving the IPCMs disconnected. Now, if IPCM1 was awaiting a status from IPCM2, there is no way to get it and relay the result to P1.

Case 2:

Consider figure 2, if there isn’t a reliable failure detection mechanism present in the system and IPCM2 sends a status message to IPCM1, then it can never be sure it reached or not without an acknowledgement. This leads to an infinite exchange of messages.

Time-outs

Time-outs are required because the system has finite resources and can’t afford to be deadlocked forever. The paper states that:

FACT 3: In a distributed system with timeouts, it is impossible to provide complete status (even if the system is absolutely reliable).

In figure 3, P1 is trying to send P2 a message through a chain of IPCMs.

Suppose if I1 takes data from P1 but before it hears about the status of the transaction, P1’s request times out. IPCM1 has now knowledge about the final outcome whether the data was successfully received by P2. Whatever status it returns to P1, it may prove to be incorrect. Hence, it’s impossible to provide complete status in a distributed facility with time-outs.

Insertion Property

An IPCM has insertion property if we insert an intermediate process P between two processes P1 and P2 that wish to communicate such that:

1. P is invisible to both P1 and P2
2. The status relayed to P1 and P2 is the same they’d get if directly connected

FACT 4: In a distributed system with timeouts, the insertion property can be possessed only if the IPCM withholds some status information that is known to it.

Delayed status is required to fulfill the insertion property. Consider that the message is sent from P1 to P2. What happens if P receives P1’s message, it goes into await-status state but it times out before P could learn about the status?

We can’t tell P1 the final outcome of the exchange as that’s not available yet. We also can’t let P know that it’s in await-status state because that would mean that the message was received by someone. It’s also not possible that P2 never received the data because such a situation cannot arise if P1 and P2 are directly connected & hence violates the insertion property.

The solution to this is to provide an ambiguous status to P1, one that is as likely to be possible if the two processes were connected directly.

Thus, a deliberate suppression of what happened is introduced by providing the same status to cover a time-out which occurs while awaiting status and, say, a transmission error.

Logical and Physical Messages

The basic function of an IPCM is the transfer and synchronization of data between two processes. This may happen by dividing the physical messages originally sent by the sender process as a part of a single operation into smaller messages, also known as logical message for the ease of transfer.

Buffer Size Considerations

As depicted in figure 5, if a buffer mismatch arises, we can take the following approaches to fix it:

1. Define a system-wide buffer size. This is extremely restrictive, especially within a network of heterogeneous systems.
2. Satisfy the request with the small buffer size and inform both the processes involved what happened. This approach requires that the processes are aware of the low level details of the communication.
3. Allow partial transfers. In this approach, only the process that issued the smaller request (50 words) is woken up. All other processes remain asleep awaiting further transfers. If the receiver’s buffer isn’t full, an EOM (End Of Message) indicator is required to wake it up.

Partial Transfers and Well-Known Ports

In figure 6, a service process using a well-known port is accepting requests for sever user processes, P1…Pn. If P1 sends a message to the service process that isn’t complete and doesn’t fill its buffer, we need to consider the following situations:

1. The well-known port is reserved for P1. No other process can communicate with the service process using it until P1 is done.
2. When the service process times out while P1 is preparing to send the second and final part of the message, we need to handle it without informing P1 that the first part has been ignored. P1 isn’t listening for incoming messages from the service process.

Since none of these problems arise without partial transfers, one solution is to ban them altogether. For example:

This is the approach taken in ARPANET where the communication to well known ports are restricted to short, complete messages which are used to setup a separate connection for subsequent communication.

Buffer Processes

This solution is modeled around the creation of dynamic processes.

Whenever P1 wishes to transfer data to the service process, a new process S1 is created and receives messages from P1 until the logical message is completed, sleeping as and when required. Then it sends the complete physical message to the service process with EOM flag set. Thus no partial transfers happen between S1 and the service process, they’re all filtered out before that.

However, this kind of a solution isn’t possible with well-known ports. S1 is inserted between P1 and the service process when the connection is initialized. In the case of well-known ports, no initialization takes place.

In discussing status returned to the users, we have indicated how the presence of certain other features limits the information that can be provided.

In fact, we have shown situations in which uncertain status had to be returned, providing almost no information as to the outcome of the transaction.

Even though the inclusion of insertion property complicates things, it is beneficial to use the weaker version of it.

Finally, we list a set of features which may be combined in a working IPCM:

(1) Time-outs

(2) Weak insertion property and partial transfer

(3) Buffer processes to allow

(4) Well-known ports — with appropriate methods to deal with partial transfers to them.