monzero-core.git/contrib/epee/include/net, branch v0.9.2Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.9.22016-03-12T15:36:18Zepee: fix bug deleting more than one connection at once2016-03-12T15:36:18Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2016-03-12T15:36:18Zurn:sha1:e98b26a87eff42d9bfcbf922e1eb9054d9fab39eUse boost::thread instead of std::thread2016-03-11T15:09:50ZHoward Chuhyc@symas.com2016-03-11T12:25:28Zurn:sha1:b937a2c915861900d047d4d4a24af31c454e3540
and all other associated IPC
Fix crash in std::map for connections_map2016-02-18T21:31:30ZHoward Chuhyc@symas.com2016-01-27T14:07:14Zurn:sha1:11d555cebe70053479f8c7ce8a8a993821b634b9
Use boost::unordered_map instead.
epee: always call the PRNG through the locked API2016-02-13T20:00:44Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2016-02-13T20:00:44Zurn:sha1:1402a526af838cb84fed344fdd553d46e1e13871epee: use generate_random_bytes for new random uuids2016-01-30T18:45:53Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2016-01-30T18:45:53Zurn:sha1:d97582cf95adc78e631286a609cbeccead9751de
Instead of using boost::uuids::generate_random, which uses
uninitialized stuff *on purpose*, just to annoy people who
use valgrind
more typos fixed2016-01-25T12:42:44ZHenning Kopphenning.kopp@uni-ulm.de2016-01-25T12:42:44Zurn:sha1:9abc4b831b01083145ef416ed20914706aad8c9aIP_TOS not supported before Windows72016-01-02T03:10:41ZHoward Chuhyc@symas.com2016-01-01T02:47:48Zurn:sha1:ee6f2cb71f4053b58be1ea15bcbe099062bbbd7cepee: regularly cleanup connections we kept a reference to2015-12-23T11:19:16Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-12-23T11:19:16Zurn:sha1:22581a04415c571461368c434ece72e5756d4fbd
Since connections from the ::connect method are now kept in
a deque to be able to cancel them on exit, this leaks both
memory and a file descriptor. Here, we clean those up after
30 seconds, to avoid this. 30 seconds is higher then the
5 second timeout used in the async code, so this should be
safe. However, this is an assumption which would break if
that async code was to start relying on longer timeouts.
epee: fix hang on exit2015-12-22T12:39:02Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-12-22T12:31:22Zurn:sha1:1e2f2d7da0ee22e35670856ad964671848e186b4
When the boost ioservice is stopped, pending work notifications
will not happen. This includes deadline timers, which would
otherwise time out the now cancelled I/O operations. When this
happens just after starting a new connect operation, this can
leave that operations in a state where it won't receive either
the completion notification nor a timeout, causing a hang.
This is fixed by keeping a list of connections corresponding
to the connect operations, and cancelling them before stopping
the boost ioservice.
Note that the list of these connections can grow unbounded, as
they're never cleaned up. Cleaning them up would involve
working out which connections do not have any pending work,
and it's not quite clear yet how to go about this.
core_rpc_server: add a --restricted-rpc option2015-11-27T18:27:24Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-11-27T18:24:29Zurn:sha1:75742977a8cd765175c1d3e39e2e74d25c6ca774
It does not expose the RPC for commands like start_mining, etc
(ie, commands a public node operator might want to be restricted)