The following post was written by @j0sh, and it describes the features in Livepeer’s upcoming Tributary release as it relates to the Livepeer Node and Command Line Interface (CLI). Look for a separate post on the protocol and smart contract updates. Tributary is set to release on 8/22/18.
Livepeeer Tributary Release Features
- Improved bond event details
- Benefits developers working building atop the Livepeer smart-contract
- Partial unbonding
- Easier way to split your token, especially after inflation
- Metrics Collection
- Opt-in to give Livepeer better visibility into overall network health
- Broadcasters can run their own metrics collector: https://github.com/livepeer/livepeer-metrics
- Restartable broadcasts
- Saves transaction costs, gets broadcasts online quicker
- Direct connections between broadcaster and transcoder
- Simplified networking model improves reliability
- Richer error reporting and feedback
Livepeer Command Line Changes
The upcoming release will see a number of changes to the command-line options for the Livepeer go client. Here is a summary of what was removed, what was added, and an explanation for each new option.
Refer to the post on upcoming network upgrades for some color behind these changes, in particular the requirement for transcoders to be publicly accessible.
This is an opt-in mechanism for broadcasters to report metrics for us to spot errors and improve the quality and reliability of the network. Disabled by default.
Use this to specify a custom metrics collection server. Broadcasters may elect to do their own metrics collection. Livepeer’s system used to collect and display metrics can be found here: https://github.com/livepeer/livepeer-metrics/
This is the IP:port that the Livepeer RTMP server listens on. Replaces the separate
Broadcaster Default: 127.0.0.1:8935
This is the IP:port that the Livepeer HTTP server listens on. Use this to play back videos, eg
Transcoder Default: 0.0.0.0:8935
The default port here comes from the ServiceURI that is stored on the blockchain when configuring the transcoder. This is the entry point for both RPC and HTTP calls.
For transcoder, the HTTP/RPC interface must be accessible to the public. Set this option if the transcoder needs to listen to a different IP:port than what is in the on-chain ServiceURI.
Most transcoders will not need to set this option. Some reasons for setting this option include:
- Transcoders are privately proxied or load balanced
- Transcoders wants to specify listeners only on a particular interface, eg on a multihomed or VPN’d setup
This is the HTTP port used by the
livepeer_cli application. This set of APIs is responsible for much of the node’s on-chain configuration: ETH and LPT withdrawals, deposits, transcode and broadcast preferences, etc.
Be very careful about setting this option unless you are confident that access is secured! In other words, don’t set something like
-cliAddr 0.0.0.0:7935 unless you know what you’re doing.
Transcoders only. Set this option if the public IP of your node differs from on-chain Service URI. The
-serviceAddr must match the on-chain Service URI. (This is a ‘soft must’ for now to give transcoders time to transition.)
When starting up, the node performs some basic connectivity checks. The public IP is auto-discovered and checked against the on-chain Service URI. If those values differ, it may be an indication that your node is in a different location than what’s advertised (and hence, unreachable to broadcasters). Setting
-serviceAddr is a way to explicitly acknowledge that discrepancy.
Some reasons for setting this option may include:
- The ServiceURI is a DNS host name
- Transcoder is part of a private, internal-only Livepeer network
- Transcoder traffic is proxied across the public network
Differences between serviceAddr and httpAddr
httpAddr: configures the IP:port that the node listens to.
serviceAddr: configures the address that we expect to see in the on-chain ServiceURI.
Under normal circumstances, neither option needs to be set. However, by setting them, the user should ensure that their node is still publicly accessible given the information that is stored on-chain. We have an open ticket to make this connectivity check automatic.