14 Commits (702a41034d908fa60fbc44792f54b3cdc9f9af2e)

Author	SHA1	Message	Date
moneromooo-monero	ed2c81ed95	replace std::list with std::vector on some hot paths ... also use reserve where appropriate	6 years ago
xmr-eric	84a7f6a482	Readd copyright starting date	7 years ago
xmr-eric	18216f19dd	Update 2018 copyright	7 years ago
moneromooo-monero	b51dc56687	use const refs in for loops for non tiny types	7 years ago
moneromooo-monero	45a1c4c088	add empty container sanity checks when using front() and back()	7 years ago
moneromooo-monero	09ce03d612	move includes around to lessen overall load	7 years ago
moneromooo-monero	8028dde7a6	block_queue: use boost::uuids::nil_uuid where appropriate	7 years ago
moneromooo-monero	5d65a75b69	move checkpoints in a separate library	7 years ago
moneromooo-monero	70b8c6d77a	cryptonote_protocol: misc fixes to the new sync algorithm ... Fix sync wedge corner case: It could happen if a connection went into standby mode, while it was the one which had requested the next span, and that span was still waiting for the data, and that peer is not on the main chain. Other peers can then start asking for that data again and again, but never get it as only that forked peer does. And various other fixes	7 years ago
moneromooo-monero	7b74760756	cryptonote_protocol: kick idle synchronizing peers ... In case they dropped off downloading for any reason, they'll get sent to download again.	7 years ago
moneromooo-monero	6edb1b3e46	block_queue: do not add empty spans	7 years ago
moneromooo-monero	08abb670e1	protocol: fix reorgs while syncing	7 years ago
moneromooo-monero	f57ee382b8	cryptonote_protocol: retry stale spans early ... Connections can be dropped by the net_node layer, unbeknownst to cryptonote_protocol, which would then not flush any spans scheduled to that connection, which would cause it to be only downloaded again once it becomes the next span (possibly after a small delay if it had been requested less than 5 seconds ago).	7 years ago
moneromooo-monero	5be43fcdba	cryptonote_protocol_handler: sync speedup ... A block queue is now placed between block download and block processing. Blocks are now requested only from one peer (unless starved). Includes a new sync_info coommand.	7 years ago