Rift VM

Motivations

Network design

VM design

Future

Motivations

Well why the hell not?

"Internet of Things"

...cloud?

Mesh protocols

P2P Applications

Goals

  • Generalize IoT around P2P principles
  • Provide a programming model which enables truly location-transparent applications
  • Democratize access to networked services

Network design

Connecting the dots

The Internet we wanted

  • Completely decentralized information network
  • Communication is transparent to sender/receiver, but opaque to handler
  • Bandwidth is limited by physical connectivity
  • Isolated networks are possible and common
  • Peer-to-peer sharing is the norm

The Internet we got

  • Hierarchical information network
  • Communication hops go through gateways
  • Bandwidth is limited by private companies
  • Isolated networks are possible but uncommon
  • Peer-to-peer sharing is done through the cloud

Client-server model

  • Clients consume services
  • Clients must know where a service exists
    • IP address, hostname, etc
  • Clients must acknowledge the limitations of the network
  • Clients must accept the authenticity of the service

Client-server model (cont.)

  • Servers provide services to clients
  • Servers must be accessible to clients
    • DNS, CDN, etc
  • Servers must acknowledge the limitations of the network
  • Servers must prove their authenticity to clients
    • SSL

Client-server model (cont.)

  • Something here about centralized services being horrible for the Internet

"Cloud" architecture

  • Typically favors thin clients
  • Fault-tolerant storage
  • High-availability services
  • Convenience in accessibility

"Cloud" architecture (cont.)

  • Verbose, overly-connected clients
    • RPC, REST, HATEOAS, etc
  • Replication of potentially sensitive data
  • Use of DNS and CDNs to distribute services geographically
  • Everything accessible everywhere

Rift architecture

  • Inherently peer-to-peer
    • No single peer is outwardly distinct from any other
  • Each peer may offer services to any other available peer
  • Each peer may consume visible services of any other available peer
  • Peers choose the visibility of their services
    • This even applies to globally-distributable services

Rift architecture (cont.)

  • Services are immutable
    • Addressable by hash
  • Services are remotely defined, but typically are locally executable
    • RPC is still used for "invisible" service dependencies such as database access
  • Services must be signed and accepted by each consuming peer

Rift architecture (cont.)

  • Network connectivity exists over multiple transports
    • 802.11s, Bluetooth, ZigBee, Unix sockets, etc
  • Location transparency
    • Multiple peers may exist on the same physical device
  • Service availability is physically and temporally defined

VM design

The devil's in the details

VM architecture

Exchange

Imports

Exports

Interpreter

Decoder

Encoder

Environment

IPC exchange

Network exchange

Filesystem exchange

Native exchange

Exchange subsystem

  • Manages all code imports and exports
  • Responsible for service visibility
  • Verifies imports
  • Signs exports
  • Interfaces with other exchanges
    • Network, IPC, filesystem, native, etc

Serialization subsystem

  • Encodes imported bytecodes
  • Decodes exported bytecodes
  • Computes service content hashes

Environment subsystem

  • Manages VM state and memory
  • Responsible for intraprocess subroutine visibility
  • Routes subroutine dispatch requests
  • Uses immutable, stack-based temporal bindings
  • Interfaces directly with the interpreter to provide subroutine dispatch and variable dereference

Interpreter

  • Register-based interpreter (stackless)
    • Heavily influenced by the Lua 5 VM
  • Single-threaded with an I/O event loop
  • Supports first-class continuations
  • Uses a small amount of wide instructions
    • 13 core instructions, with up to 5 operands

Implementation constraints

  • Implemented in Go
    • Platform independence, small memory footprint, C compatibility
  • Indirect memory management
    • Uses the host runtime for allocation and collection
  • First-class continuation support is limited to intraprocess
  • Network exchange implement using WiFi
    • Multicast for service visibility and unicast for service consumption

Future

Just over the horizon

What's next?

  • Bootstrap VM
  • OpenPDS implementation
  • Bluetooth LE exchange
  • ZigBee exchange
  • Native library exchange
  • Better-integrated Android target
  • iOS target
  • Rift compiler?

Questions?

Rift VM

By Jeremy Lucas

Rift VM

An introduction to the Rift VM, including both the high level goals of the project and some of the nitty-gritty internals.

  • 669
Loading comments...

More from Jeremy Lucas