Deep Atlantic Storage: Reading File Upload in Web Workers

I'm bored on 4th of July holiday, so I made a wacky webpage: Deep Atlantic Storage. It is described as a free file storage service, where you can upload any file to be stored deep in the Atlantic Ocean, with no size limit and content restriction whatsoever. How does it work, and how can I afford to provide it?

This article is the second of a 3-part series that reveals the secrets behind Deep Atlantic Storage. The previous part introduced the algorithm I use to sort all the bits in a Uint8Array. Now I'd continue from there, and explain how the webpage accepts and processes file uploads.

File Upload

File upload has always been a part of HTML standard as long as I remembered:

<form action="upload.php" method="POST" enctype="multipart/form-data">
  <input type="file" name="file">
  <input type="submit" value="upload">
</form>

Deep Atlantic Storage: Sorting Bits

I'm bored on 4th of July holiday, so I made a wacky webpage: Deep Atlantic Storage. It is described as a free file storage service, where you can upload any file to be stored deep in the Atlantic Ocean, with no size limit and content restriction whatsoever. Since Chia currency farming became popular in May, hard drive prices went up significantly. How can I afford to operate an unlimited free storage service?

"Advanced Sorting Technology"

One of the benefits listed on Deep Atlantic Storage webpage is:

  • Advanced sorting technology keeps your data neatly ordered.

What this means is that, content in the uploaded file would be sorted before being stored.

NDN Video Streaming over QUIC

NDN over WebSockets == TCP over TCP

Named Data Networking (NDN) was first ported to web browser environment in 2012. At that time, a browser-based JavaScript application can communicate with the Internet via either XMLHTTPRequest or WebSocket. Feeling that WebSocket is a better match for the NDN implementation at the time, I wrote the initial code for a CCNx WebSocket proxy.

Web applications would connect to this proxy over TCP, negotiate a WebSocket connection, and send NDN packets in WebSocket frames. The proxy then decapsulates these frames, and delivers the NDN packets to ccnd forwarder over TCP.

NDN-over-WebSockets survived multiple protocol changes over the years, and made its way into the NDN Forwarding Daemon (NFD). It worked fine for simple NDN web applications, such as status pages and text chat, and even file retrievals.

Recently, with the rise of video streaming on the NDN testbed, congestion control functionality starts to show up in NDN libraries. Then, a question popped into my mind: WebSockets run over TCP, and NDN congestion control algorithms are largely borrowed from TCP, would this cause any problems?

The Reality of NDN Video Streaming

As of 2019, video accounts for over 60% of downstream traffic on the Internet. It is believed that video streaming could benefit from the in-network caching feature of Named Data Networking (NDN), which would reduce the total traffic volume and bring cost savings for Internet service providers and content publishers. Far Cry: Will CDNs Hear NDN's Call?, a paper published at ACM-ICN 2020 conference, is the latest attempt on NDN video streaming.

How iViSA Works

In Far Cry, the authors implemented iViSA, a browser-based video streaming application that runs on the global NDN testbed, and then performed some comparison study between this application and similar HTTP video streaming application deployed on commercial CDN services.

It's said that if you want reproducible science, the software needs to be open source. The authors released most of their source code, and we can get a peek into how iViSA actually works.

The backend server repository contains:

Self-Hosted NDNts Nightly Build

NDNts nightly build is a set of NPM-compatible tarballs compiled automatically from the development branch of NDNts, Named Data Networking (NDN) libraries for the modern web, distributed on https://ndnts-nightly.ndn.today website. Users can install NDNts nightly build following these instructions.

However, this website only stores the latest version of NDNts packages. This has been causing installation conflicts when NPM tries to look for previous versions. Moreover, as I have declared, I don't care much about backwards compatibility. With NPM, all published versions are stored indefinitely, so you can continue using an older version without being affected by breaking changes. On the other hand, once a new nightly build is uploaded, the previous version is overwritten and no longer available for downloads. You are then forced to cope with the breaking changes I introduce from time to time, possibly at higher frequency than you would like to.

Today, I'm introducing two methods for self-hosting NDNts nightly build. Both methods allow you to build a specific version of NDNts codebase from a checkout of the NDNts monorepo, and generate a set of tarballs that you can host locally on a server under your control. Afterwards, you can install NDNts packages from this server, without relying on my website and without being affected by my breaking changes.

Self-Hosted NDNts on an HTTP Server

The following steps allow you to create and host tarballs of one specific version of NDNts.

Where does GMT-0456 Timezone Come From?

Recently, someone on the DCTech Slack community asked why the Date.prototype.toDateString function is having an off-by-one error:

new Date("2020-10-17").toDateString();
"Fri Oct 16 2020"

My immediate response was: timezone. The group then proceeded to discover that the Date constructor would interpret a date-only string as being in UTC timezone. Washington, DC uses Eastern Daylight Time that is four hours behind UTC, so the timezone of the constructed Date object is 20:00:00 local time on the previous date. Since toDateString uses local time, it prints as the previous date.

After that, I started testing some boundary conditions:

new Date("0001-01-01").toString()
"Sun Dec 31 0000 19:03:58 GMT-0456 (Eastern Standard Time)"

new Date("0000-01-01").toString()
"Fri Dec 31 -0001 19:03:58 GMT-0456 (Eastern Standard Time)"

Getting Started with NDNts Web Application using webpack

This article shows how to get started with NDNts, Named Data Networking (NDN) libraries for the modern web. In particular, it demonstrates how to write a consumer-only web application that connects to the NDN testbed, transmits a few Interests, and gets responses. This application uses JavaScript programming language and webpack module bundler.

Prepare the System

To use NDNts, you must have Node.js. As of this writing, NDNts works best with Node.js 14.x, and you should install that version. The easiest way to install Node.js is through Node Version Manager (nvm) or Node Version Manager (nvm) for Windows.

On Ubuntu 18.04, you can install nvm and Node.js with the following commands:

$ wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.36.0/install.sh | bash
$ nvm install 14
Now using node v14.14.0 (npm v6.14.8)

NDNts Nightly Build

NDNts nightly build is a set of NPM-compatible tarballs compiled automatically from the development branch of NDNts, Named Data Networking (NDN) libraries for the modern web. They are built by the Continuous Integration (CI) system and uploaded to the NDNts nightly build website: ndnts-nightly.ndn.today. Homepage of that website displays a list of URIs of available tarballs.

How to install NDNts nightly build

You can find available tarballs on NDNts nightly build website: ndnts-nightly.ndn.today.

To install a tarball as a local dependency within the current project, you can execute something like:

$ npm install https://ndnts-nightly.ndn.today/packet.tgz
+ @ndn/packet@0.0.20200822-nightly.a471902
added 5 packages from 3 contributors and audited 5 packages in 1.612s
found 0 vulnerabilities

Getting Started with NDNts in Node.js

This article shows how to get started with NDNts, Named Data Networking (NDN) libraries for the modern web. In particular, it demonstrates how to write a producer and a consumer application in Node.js using JavaScript programming language, and transmit a few Interest and Data packets via NFD forwarder on the local machine.

Prepare the System

This guide is written for Ubuntu 18.04 operating system. If you have a Windows PC, you can enable Windows Subsystem for Linux and install Ubuntu 18.04 from the Microsoft Store. If you have a Macbook or a Linux machine other than Ubuntu 18.04, you can install Vagrant, and create a virtual machine using bento/ubuntu-18.04 template. All steps below should be executed inside Ubuntu 18.04 environment.

To use NDNts, you must have Node.js. As of this writing, NDNts works best with Node.js 14.x, and you should install that version. The easiest way to install Node.js is through Node Version Manager (nvm). To install nvm and then install Node.js, type the following commands in Ubuntu 18.04 terminal:

$ wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash
$ nvm install 14
Now using node v14.2.0 (npm v6.14.4)

Introducing NDNts, Named Data Networking libraries for the Modern Web

I'm creating a new Named Data Networking (NDN) client library, NDNts. The initial NPM release, v0.0.20191223-beta.1, was uploaded yesterday. This article explains why I'm doing this, and why you should consider using my library.

Motivation

I've been developing Named Data Networking (NDN) for several years. Although my specialty is in the forwarding plane, I occasionally build NDN applications, such as a home surveillance camera. A common ingredient of every NDN application is some sort of client libraries, which provides APIs that allow the application to encode/decode NDN packets and communicate over NDN networks in accordance with the NDN protocol. One of these client libraries is the NDN Common Client Libraries (NDN-CCL), which provide a consistent API across several programming languages.

I adopted ndn-js, the JavaScript variant of NDN-CCL, in several projects, and was unhappy about it:

  • The API feels like Java, not JavaScript.
  • Callbacks everywhere, leading to callback hell.
  • The library inserts over 50 symbols to the browser's global scope, causing name conflicts.
  • All features are bundled into a single file that weighs over 500KB.
  • There's no unit testing for the most part, let alone continuous integration.