toolchain update.
The lints are `collapsible_match` and `manual_option_zip`.
`collapsible_match` made the match arms inconsistent and made them
reliant on being followed by a no-op wildcard arm.
`manual_option_zip` has a bug in our current version where it suggests
transforming conditional calls into unconditional calls.
Context: After much ado, in 2021 according to RFC 3052 the authors
field was made optional, with the possibility of deprecation being held
open for the future. After four years, it doesn't seem people have come
much back around to the feature; in pull #15068 on the cargo repository
from January of this year, it was finally marked as deprecated in the
documentation.
Most of these kinds of attributes are pretty pointless for us anyways,
since we don't publish to crates.io, and the reasons for making it
optional/deprecated mostly apply to us as well. It just doesn't seem
very useful.
- ordered-float from 4 to 5
- strum from 0.26 to 0.27
- profiling from 1.0.16 to 1.0.17 and tracing-tracy from 0.11.3 to 0.11.4
- toml from 0.8 to 0.9
- socket2 from 0.5 to 0.6
- indicatif from 0.17 to 0.18
- crossterm from 0.28 to 0.29
- fluent from 0.16 to 0.17, fluent-bundle from 0.15 to 0.16, and
fluent-syntax from 0.11 to 0.12
Also moved criterion to workspace dependencies, and removed
assets_manager from voxygen since it doesn't appear to be used.
This contains a lot of renaming, in rand, thread_rng got changed to rng and gen got changed to random because of the upcomming rust2024 edition.
Additionally the traits are changing.
This is highly necessary for a toolchain update
attempt to subtract with overflow
This can happen when cur_bytes get increased in 132, we break the inner loop, but the next iteration on the outer loop will have `cur_bytes` > `total_bytes`.
This check is only active on dev instances, thus hard to catch.
With breaking the outer loop, we might "starve" a few streams when 2 streams share the same prio but there is only enough bandwidth to feed the first.
However: this only becomes an issue when this happens for a longer time. Additionally therre is the `guaranteed_bandwidth` to take care of this issue.
An alternative would be to move the check from line 133-135 out of the `for` loop, which would result in sending a few bytes to much, but be `fair` inside a single prio level.
We calculate a max bandwidth, but due to framing the packages, i think its possible for the current_bytes to get a few bytes over the actuall planed bandwidth. which prob isn't that bad/unfair
cannot update the following dependencies:
- vek: Sharps SIMD isnt upstream
- tracing-subscriber: MakeWriter was adjusted and i was to lazy to fiddle with lifetimes,
- refinery, rustsql: we have a custom refinery version which is incompatible with newer rustsql
- equi + egui_winit + egui_wgpu_backend: i tried it in this commit but it turned out that they dependo n wgpu which we cant update
- wgpu: cant update due new version doesnt support DX11
Got quinn updated which now require some dependencies to be explicit.
When local SendProtocol is opening a Stream, it will send a empty message to QuicDrain which will then know that its time to open a quic stream.
It will open a QuicStream and send its SID over to remote.
The RecvStream will be send to local QuicSink
RemoteRecv will notice a new BiStream was opened and read its Sid. It will now start listening on it. while remote main will get the information that a stream was opened and will notice the frontend.
in participant remote Recv is synced with remote send (without triggering a empty message!).
RemoteRecv Sink will send the sendstream to RemoteSend Drain and it will be used when a first message is send on this stream.
- locally we open a stream, our local Drain is sending OpenStream
- remote Sink will know this and notify remote Drain
- remote side sends a message
- local sink does not know about the Stream. as there is (and CANT) be a wat to notify local Sink from local Drain (it could introduce race conditions).
One of the possible solutions was, that the remote drain will copy the OpenStream Msg ON the Quic::stream before first data is send. This would work but is complicated.
Instead we now just mark such streams as "potentially open" and we listen for the first DataHeader to get it's SID.
add support for unreliable messages in quic protocol, benchmarks
If its Closed it looks like the TCP connection got dropped/cut off (e.g. OS, Wifi).
If its Violated we for sure know the cause is the messages send/recv in a wrong way
Its available to `api` and `metrics` and can be used to slow down msg send in veloren.
It uses a tokio::watch for now, as i plan to have a watch job in the scheduler that recalculates prio on change.
Also cleaning up participant metrics after a disconnect
When a stream is opened we are searching for the best (currently) available channel.
The stream will then be keept on that channel.
Adjusted the rest of the algorithms that they now respect this rule.
improved a HashMap for Pids to be based on a Vec. Also using this for Sid -> Cid relation which is more performance critical
WARN: our current send()? error handling allows it for some close_stream messages to get lost.
