mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.6.0 2025-08-18T16:09:04Z 2025-08-18T16:09:04Z Gabriela Moldovan gabi@torproject.org 2025-08-18T15:52:38Z urn:sha1:702e7276898d3f31e22033c5b64fea91703f3701 The `stream` module is client-specific, for the most part, so I am moving it under `client`. Later on, we will factor out the parts that can be shared with the relay implementation. Note: this is a breaking change as the deleted `stream` module was `pub`. We could've kept the module and reexported from it the public types from `tor_proto::client::stream`, but I think it's better to have this `client` namespacing, because it makes the separation between the client and relay parts clearer. 2025-08-07T15:28:36Z Nick Mathewson nickm@torproject.org 2025-08-06T01:19:58Z urn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again. 2025-04-08T17:20:50Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-08T11:50:17Z urn:sha1:e02da4600e7a66bee5ac3dc57b708c0942bda895 Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185872 2025-04-08T17:20:50Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-02T16:23:22Z urn:sha1:016bcdbe6e93d7a565e33640c1363d5a79c7472d 2025-04-08T17:20:50Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-02T16:21:39Z urn:sha1:e9ee2f4204b5139de9946d86c942b6e62427f258 This proves the concept. Many more metrics will need to be added throughout the codebase. With this compiled in and enabled, I see this with curl: > ``` > # TYPE arti_hss_proxy_connections_failed_total counter > arti_hss_proxy_connections_failed_total{nickname="ztest",action="destroy_circuit"} 0 > arti_hss_proxy_connections_failed_total{nickname="ztest",action="ignore_stream"} 0 > arti_hss_proxy_connections_failed_total{nickname="ztest",action="forward"} 0 > arti_hss_proxy_connections_failed_total{nickname="ztest",action="reject_stream"} 0 > > # TYPE arti_hss_proxy_connections_total counter > arti_hss_proxy_connections_total{nickname="ztest",action="reject_stream"} 0 > arti_hss_proxy_connections_total{nickname="ztest",action="forward"} 1 > arti_hss_proxy_connections_total{nickname="ztest",action="destroy_circuit"} 0 > arti_hss_proxy_connections_total{nickname="ztest",action="ignore_stream"} 0 > > # TYPE arti_hss_proxy_connections_ok_total counter > arti_hss_proxy_connections_ok_total{nickname="ztest",action="destroy_circuit"} 0 > arti_hss_proxy_connections_ok_total{nickname="ztest",action="reject_stream"} 0 > arti_hss_proxy_connections_ok_total{nickname="ztest",action="ignore_stream"} 0 > arti_hss_proxy_connections_ok_total{nickname="ztest",action="forward"} 1 > ``` 2025-04-08T17:20:50Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-04-02T14:25:17Z urn:sha1:65d8df00f87e70673cd46df699db71a66998e8aa This means that we can use the same variable names for the clones, which is considerably less confusing. 2024-08-28T14:27:46Z Jim Newsome jnewsome@torproject.org 2024-08-22T19:20:36Z urn:sha1:46f7f01092e6ac55e3e958dc3a2228b1d36e26a1 Having this in the `tor-async-utils` crate prevents us from doing both of the following without introducing a circular dependency: * using it in `tor-rtmock` (which we currently do, particularly in tests). * using `tor-rtmock` to test things in `tor-async-utils`. We don't do this yet, but it is generally sensible to do so. In particular we want to move the `stream_peak` module there, which is currently tested with `tor-rtmock`. Moving this into its own crate avoids this circular dependency. 2024-01-16T16:56:28Z Nick Mathewson nickm@torproject.org 2024-01-16T16:56:28Z urn:sha1:36dcbe9382e12f32d2aecb159c8b51c14871a701 I'm taking this out for now since we don't have support for actually making these addresses work, and the current behavior will just ignore connections silently. Closes #1245 2024-01-09T19:59:18Z Nick Mathewson nickm@torproject.org 2024-01-09T19:59:18Z urn:sha1:c062efb82ee26c538477b5ffd95c255246bfff44 2023-12-11T18:08:13Z Ian Jackson iwj@torproject.org 2023-12-11T18:08:13Z urn:sha1:19546723df1b94af599315b706c7068f60ca3c44