This function always appends to an existing string, so by passing it a
String directly we can avoid superfluous allocations.
Also tokio-xmpp was doing a bunch of &str to String for no reason around
there, let’s remove that too.
insecure-tcp requires the io-util feature of tokio, so let’s enable it
there.
Fixes this error:
5 | use tokio::{io::BufStream, net::TcpStream};
| ^^^^^^^^^^^^^ no `BufStream` in `io`
The Client::send_stanza method blocks on the stanza actually being sent
over the stream. Without this change, the method will never return
on streams without XEP-0198 Stream Management because `sm_state` is
then None and thus the StanzaToken's state is never advanced: it would
be stuck in Queued state.
In addition, a lack of advancement to Sent state may cause a deadlock on
XEP-0198-enabled streams if data is received so fast that the
frontend_tx mpsc::Sender in the stanzastream::Worker is filled up. In
such a case, the Worker cannot obtain a permit and will only service
writes. However, that will mean that no StanzaTokens can be advanced
beyond Queued state, because for that, reads need to be serviced (to
receive the SM acks).
If a burst of stanzas is then received while Client::send_stanza is
being awaited, send_stanza can only return if something reads from the
frontend mpsc in the meantime. We do not want to require user code to
drive the Client in full-duplex mode, hence this is a bug.
skip-changelog, because this fixes an unreleased feature.
Instead of having a second method to fetch channel-binding from the
TlsStream, do it directly in the connect() method, since after that we
don’t have enough information to fetch it any longer when using ktls.
This allows to use any serialisable type. The advantage is that moves
and clones are avoided (which would otherwise be needed to construct
e.g. a XmppStreamElement from a Stanza or Message).
This drastically improve the debuggability of the network parts, by
moving the task of encrypting/decrypting TLS packets from userland to
the kernel. This makes them appear in clear in strace as sendto() and
recvfrom().
I introduced a new tls-rust-ktls feature which depends on both rustls
and ktls, but isn’t enabled by default since it probably isn’t available
on every computer. It requires the tls kernel module to be loaded,
which then can offload encryption/decryption to dedicated hardware if
available.
I have tested this change on Linux 6.11 on a rk3588.
First switch to LazyLock from OnceLock, to simplify the code.
Then concatenate the colour reset escape code instead of using
format!(), since the vast majority of those strings have more capacity
than their length it will avoid a reallocation in most cases.
This allows to detect and handle dying streams without getting stuck
forever.
Timeouts are always wrong, though, so we put the burden of choosing the
right values (mostly) on the creator of a stream.
Without the early return in XmlStream::poll_next in case of the stream
footer, the read state gets recreated and the logic at the top of that
function to actually handle stream shutdown gracefully is never
triggered.
Also that logic was incorrect; the correct behaviour is to wait for the
true EOF.
This makes the stream resets a lot safer, by preventing the forbidden
send-read-reset combination of events: the reset function on the
responder side now takes the element to send right before the reset,
enforcing a send-reset pattern.
