mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.2.0 2022-03-16T16:34:44Z 2022-03-16T16:34:44Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-03-16T14:52:12Z urn:sha1:da787d074a04c97a1e28709f53f1cff5127b7ac9 This has the different syntax for builder field attributes than what I originally proposed in my MR, and which therefore is in the pinned branch. My upstream MR for the field attributes feature was morged: https://github.com/colin-kiegel/rust-derive-builder/issues/239 2022-03-07T15:56:57Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-03-04T15:09:16Z urn:sha1:416b56d852a74ff8f8a2e6f1794c8390f9b08afe We are going to want to specify custom attributes on fields of the builder struct. This feature was missing from derive_builder. This commitid is the current head of my MR branch https://github.com/colin-kiegel/rust-derive-builder/pull/237 https://github.com/ijackson/rust-derive-builder/tree/builder-field-attrs Using the commitid prevents surprises if that branch is updated. We will require this newer version of derive_builder. The version will need to be bumped again later, assuming the upstream MR is merged and upstream do a release containing the needed changes. 2022-03-04T18:00:17Z Ian Jackson iwj@torproject.org 2022-03-04T18:00:17Z urn:sha1:b0952652579dc75de19589873e3853d0b13a6965 Replace many manual trait impls with use of educe See merge request tpo/core/arti!375 2022-03-04T11:45:24Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-03-04T11:13:29Z urn:sha1:aba68088d16569b586eebc45e8bbcd027415b6a5 Empty crate right now 2022-03-03T18:05:30Z Nick Mathewson nickm@torproject.org 2022-03-02T15:03:19Z urn:sha1:9329c7b878eadba0344802632b97f23524c9d8f3 This commit adds a new program to try to implement the ideas behind experimentation in arti#329. In particular, it tries to implement basic client "can I bootstrap and connect" functionality testing, with a lot of instrumentation, and support for breaking things. So far, the instrumentation is limited to counting TCP bytes and connections, and counting events. Still, this is enough to measure behavior on some of the incorrect-clock tests. NOTE: For now, you are _required_ to pass in an explicit configuration, in hopes that this will lead you to override your storage directories for doing specific experiments. 2022-02-23T13:55:14Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-02-23T11:59:36Z urn:sha1:0f80be6b35e38b93f89700b62f2d78955435823a 2022-02-04T14:33:09Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-01-12T17:16:18Z urn:sha1:9e5b6fa820c2dc4c6c07d7de8724d5d5fb4ed747 As per doc/Errors.md. Currently there are no error kinds. Some will be added as we go along. 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.