wip
voting
wip
move voting into the replicate stage
update
fixup!
fixup!
fixup!
fixup!
fixup!
fixup!
fixup!
fixup!
fixup!
fixup!
update
fixup!
fixup!
fixup!
tpu processing votes in entries before write stage
fixup!
fixup!
txs
make sure validators have an account
fixup!
fixup!
fixup!
exit fullnode correctly
exit on exit not err
try 50
add delay for voting
300
300
startup logs
par start
100
no rayon
retry longer
log leader drop
fix distance
50 nodes
100
handle deserialize error
update
fix broadcast
new table every time
tweaks
table
update
try shuffle table
skip kill
skip add
purge test
fixed tests
rebase 2
fixed tests
fixed rebase
cleanup
ok for blobs to be longer then window
fix init window
60 nodes
UPnP is now used to request a port on the NAT be forwarded to the local machine.
This obviously only works for NATs that support UPnP, and thus is not a panacea
for all NAT-related connectivity issues.
Notable hacks in this patch include a transmit/receive UDP socket pair to work
around current protocol limitations whereby the full node assumes its peer can
receive on the same UDP port it transmitted from.
Now that the Bank is single-threaded again, we can spin up new
accounts on the fly without concern of thread contention. Likewise,
we can send all transactions from a single account, which was also
problematic in the multi-threaded bank. Sending from one account will
also make client-demo straightforward to port to solana-drone.
pnet_transport takes a long time to build. It's been especially
painful from within a docker container for reasons I don't care
to understand. pnet_datalink is the only part of pnet we're using
so booting the rest.
We added them thinking it'd be a good stepping stone towards an
asynchronous thin client, but it's used inconsistently and where
it used, the function is still synchronous, which is just confusing.
poll both endpoints in client
logs
logs
logs
names
verify plan not sig
log
set udp buffer to max
drop output
more verbose about window requests
log the leader
load leader identity
readme for single node demo
update
asserts
update
replay all
rsync
dynamic file read in testnode
fix
cleanup
readme
sum
fix scripts
cleanup
cleanup
readme
The terms Stub and Skel come from OMG IDL and only made sense while
the Stub was acting as an RPC client for the the Accountant object.
Nowadays, the Stub interface looks nothing like the Accountant and
meanwhile we've recognized the multithreaded implementation is more
reminiscent of a pipelined CPU. Thus, we finally bite the bullet and
rename our modules.
AccountantSkel -> Tpu
AccountantStub -> ThinClient
Up next will be moving much of the TPU code into separate modules,
each representing a stage of the pipeline. The interface of each
will follow the precedent set by the Historian object.