mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.3 2021-12-16T16:12:59Z 2021-12-16T16:12:59Z eta tor@eta.st 2021-12-14T17:29:04Z urn:sha1:06a94288caa6cdb61d90982f171b7da688951b6b The new `arti-bench` crate does a simple end-to-end benchmark test embedding Arti: it generates some random data (of configurable amount, depending on command-line parameters), and then sends said data back and forth via Arti (which should be configured to use a local Chutney network). Additionally, the benchmark can also be run via a local SOCKS5 server (in order to benchmark the performance via a local Chutney node, for comparison). The `tests/chutney/arti-bench.sh` sets up and tears down Chutney as required to make this work. This is very much a first cut; there are many things that should eventually get added, such as support for multiple connections, JSON output capabilities, running multiple tests, ... 2021-11-22T14:40:18Z eta tor@eta.st 2021-11-22T14:40:18Z urn:sha1:ee2ec31ede1afbf1bf60e8aa33ca1455a8d30cb1 This commit message totally gives away the cursed way in which I use git. branches? what are those? 2021-11-22T14:39:38Z eta tor@eta.st 2021-11-16T15:21:47Z urn:sha1:98f38dc186212624d377653ed8ecf3c47366c3ad This implements a basic typed event broadcast mechanism, as described in arti#230: consumers of the new `tor-events` crate can emit `TorEvent` events, which others can consume via the `TorEventReceiver`. Under the hood, the crate uses the `async-broadcast` (https://github.com/smol-rs/async-broadcast) crate, and a `futures::mpsc::UnboundedSender` for the event emitters; these are glued together in the `EventReactor`, which must be run in a background thread for things to work. (This is done so event sending is always cheap and non-blocking, since `async-broadcast` senders don't have this functionality.) Additionally, the `TorEventKind` type is used to implement selective event reception / emission: receivers can subscribe to certain event types (and in fact start out receiving nothing), which filters the set of events they receive. Having no subscribers for a given event type means it won't even be emitted in the first place, making things more efficient. 2021-11-18T16:37:48Z Nick Mathewson nickm@torproject.org 2021-11-17T19:16:55Z urn:sha1:5184f5ba84d76b75022fe6249ba18fe42807b1aa To do this at all neatly, I had to split out `tor-config` from `arti-config` again, and putting the lower level stuff (paths, builder errors) into tor-config. I also changed our use of derive_builder to always use a common error type, to avoid error type proliferation. 2021-11-08T19:33:10Z Nick Mathewson nickm@torproject.org 2021-11-08T19:19:02Z urn:sha1:487524c0224cb117dfd151ad9976ce539702639c By enabling link-time optimization, setting 'opt-level=s', and setting compilation-units=1, we can get a much smaller download size, which is one of our objectives. Making these changes reduces the binary size for me (on x86_64) by about 42%. If you also run "strip --strip-debug" on the resulting binary, the resulting size is 55% smaller than the original binary size. These effects persist if you compress the binary. Supposing that we use xz compression, these options make save 32% of compressed binary size. If we also "strip --strip-debug" before compressing, the compressed binary saves 43% from the original binary size. With all of these options applied, on x86_64 linux with xz compression, we're at a nice 1.5 MiB download. If we statically link to openssl and sqlite, we're still only at a 2.8 MiB download. There is a build time cost to these changes: for me, it comes to a 10%-25% build time increase. This is part of arti#172. 2021-10-21T18:22:11Z Nick Mathewson nickm@torproject.org 2021-10-21T18:15:13Z urn:sha1:7c7a388e287afa0e168d8d666da6649a5750b9b5 Solves a name conflict with the existing tor_client create. Closes #130. 2021-10-07T14:45:42Z Nick Mathewson nickm@torproject.org 2021-09-10T15:18:24Z urn:sha1:0779923d6474bb72427d19b2e504b3fd370b78a2 There are some missing parts here (like persistence and tests) and some incorrect parts (I am 90% sure that the "exploratory circuit" flag is bogus). Also it is not integrated with the circuit manager code. 2021-08-27T13:53:09Z Nick Mathewson nickm@torproject.org 2021-08-27T13:53:09Z urn:sha1:557a0ff40b3731d4690767de27010bbeff08777d This will cause some pain for now, but now is really the best time to do this kind of thing. 2021-08-06T20:39:50Z Nick Mathewson nickm@torproject.org 2021-08-02T11:42:36Z urn:sha1:bb6d38cde05ce6038670741afa9d93cecaf3a642 This commit defines a crate (tor-persist) that describes an abstract key-value store using serde, plus an on-disk implementation using Toml and fslock. 2021-06-24T15:44:54Z Nick Mathewson nickm@torproject.org 2021-06-24T15:44:54Z urn:sha1:1d16bcf16bcdb73fba5574a8dc29973c1225295e