Create two A records within your domain DNS:
<HOSTNAME>. 300 IN A <IP>
*.<HOSTNAME>. 300 IN A <IP>
Install git (for kustomize)
Install k3s
[root@da4624330650 /]# dnf --enablerepo=fedora-debuginfo --enablerepo=updates-debuginfo repoquery -l openssl-libs | |
Fedora 27 - x86_64 - Updates 3.5 MB/s | 25 MB 00:07 | |
Fedora 27 - x86_64 - Updates - Debug 1.1 MB/s | 15 MB 00:12 | |
Fedora 27 - x86_64 1.2 MB/s | 58 MB 00:47 | |
Fedora 27 - x86_64 - Debug 1.0 MB/s | 26 MB 00:25 | |
Last metadata expiration check: 0:00:08 ago on Tue Jul 17 16:56:59 |
var bluebird = require('bluebird'); | |
var Promise = bluebird.Promise; | |
var Remote = require('ripple-lib').Remote; | |
function measureThroughput() { | |
return new Promise(function(resolve, reject) { | |
var remote = new Remote({ | |
servers: [ 'wss://s.altnet.rippletest.net:51233' ] | |
}) |
apiVersion: extensions/v1beta1 | |
kind: Ingress | |
metadata: | |
name: acme-dns | |
namespace: acme-dns | |
annotations: | |
kubernetes.io/ingress.class: "traefik" | |
spec: | |
rules: | |
- host: "acme.codius.example.com" |
StreamReceipt ::= SEQUENCE { | |
-- Identifier of the stream | |
streamId VarUInt, | |
-- Length-prefixed Receipt for verifying the total amount received on this stream | |
-- The sender is not expected to decode the Receipt fields but must be able to decode the | |
-- receipt string in the frame, even if it represents an unsupported Receipt version | |
receipt Receipt | |
} |
StreamReceipt ::= SEQUENCE { | |
streamId VarUInt, | |
receipt Receipt | |
} | |
RECEIPT ::= CLASS { | |
&typeId UInt8 UNIQUE, | |
&Type | |
} WITH SYNTAX {&typeId &Type} |
Create two A records within your domain DNS:
<HOSTNAME>. 300 IN A <IP>
*.<HOSTNAME>. 300 IN A <IP>
Install git (for kustomize)
Install k3s
wilsonianb |
{ | |
"spec": { | |
"containers": [ | |
{ | |
"name": "app", | |
"image": "nginx@sha256:3e2ffcf0edca2a4e9b24ca442d227baea7b7f0e33ad654ef1eb806fbd9bedcf0", | |
"command": [ | |
"nginx", | |
"-g", | |
"daemon off;" |
This proposal describes an alternative to Tickets for solving the problem of one transaction blocking another due to the sequence number ordering.
Instead of preemptively designating account sequence numbers to be used at a later time (using tickets), XRP Ledger can allow account transactions to happen out of sequence order.
The most important role of the Sequence number is that it makes each transaction on an account unique.
We can ensure that no sequence number is used more than once by storing what sequence numbers have been skipped for an account. An account would have: