Implement support for the TCP protocol, based on `async-io` (STD-only)

[ivmarkov]

Support for TCP is actually half-way (or even a bit more?) there in that we already:

• Support TCP addressing
• Disable the "Reliability" MRP code path for packets which have the R flag (used for BTP already)
• Support large packets - need to double-check if these packet sizes conform to the Matter Core Spec
• Support initialization of large packet buffers in the transport, with feature large-buffers
• rs-matter core is agnostic to the concrete transport, and moreover - transports can be chained, where chaining is already used during concurrent commissioning for chaining BTP and UDP

What needs to be done:

Add a tcp.rs implementation on top of async-io similar to the udp.rs one:

• Support TCP accept and add the accepted TCP stream to a pool of streams, where each stream is keyed by its TCP address. Think what to do when we get two tcp streams with the same peer TCP address? Perhaps we should just close the earlier one, without sending any exchange Close Matter message, as likely, the other peer considers the older stream "stale" if it is opening a new one?
• Support TCP connect and add the connected TCP stream to the pool of streams; necessary when a subscription needs to send data to a peer which does not have an opened TCP stream ATM; or in general for any outgoing message - if the peer to which the message is addressed does not have an opened TCP stream in the streams' pool, such one needs to be opened (with connect) on-the-fly;
• Support eviction of closed/timing-out/stale TCP streams from the pool of streams. TCP stream closure can be detected when reading from the TCP stream (so that we get the FIN from the other peer). The TCP impl would therefore likely need to constantly poll the streams in the stream pool for readable and close those where it gets a FIN. This would naturally happen in its NetworkReceive::wait_available and NetworkReceive::recv_from impls, but we also need user-configurable timeouts for NetworkReceive::recv_from and NetworkReceive::send_to
• We might need to also time-out streams where we have not received anything for a very long time (long timeout). Need to check if/how the C++ SDK does this. Also good to check the TCP impl of the C++ SDK anyway
• Think whether a TCP stream need to be eagerly closed when an exchange on that stream is over. Check how the C++ SDK does it. It is likely not doing an eager close and is re-using the streams across exchanges and for multiple exchanges with the same peer, as the Matter Core Spec seems to hint at using TCP keep alive ACKs for "long living" TCP streams
• Advertise TCP support via mDNS

I would say, a relatively easy and straight-forward task.

[ivmarkov]

This paragraph in the Core Spec 1.4 is a bit puzzling:

Unlike MRP, which does not rely on an underlying connection, a secure session over TCP is unusable when
its connection is broken or is closed. Nodes MAY choose to remove the secure session when the connection goes down. If the session is retained after the connection goes away, then the session
SHALL be marked appropriately so that the underlying connection is re-established before the session can be used again. Moreover, the session resumption state MAY be retained to expedite session
establishment when the connection is re-established with the corresponding peer.

While it is clear that a session is associated with a concrete transport (also in rs-matter - we have the peer address in the Session struct), it is unclear to me why any special Matter Session resumption needs to be done on re-establishment of the TCP socket connection? After all, the new TCP socket should get the same destination address, so from the point of view of our session, it will be indistinguishable from the previous TCP stream to the same peer?

It is true though that the other peer might see a different TCP address for ourselves, because - unlike UDP bind - with TCP connect - it will see as our src TCP port an ephemeral one. Wondering if a TCP connect can be forced to be on a predefined non-ephemeral port, just like what happens with TCP accept? Seems maybe yes but wondering how much effort that would be from within Rust, and also for ESP-IDF lwIP, and for smoltcp: https://blog.cloudflare.com/pt-br/how-to-stop-running-out-of-ephemeral-ports-and-start-to-love-long-lived-connections/#manually-selecting-source-ip-address

[ivmarkov]

It might just be easier if we close each Session when the TCP stream associated with it is closed as well. We might or might not have to then keep our "src" IP+port in Address::Tcp. If we don't keep it, then we should probably do the "bind-before-connect" ^^^ trick from above.

[gmarcosb]

I can help out with this one once I do some of the easier issues to get a hang of rust; I've been elbow-deep in TCP & have submitted a bunch of PRs fixing a ton of issues in C++ (most of which won't happen in rust, the C++ ref-counting impl was terrible)

[ivmarkov]

Be my guest!
Just be prepared that I'm a bit opinionated on the exact shape of the TCP layer as I've fiddled with networking quite a bit in the meantime :) (and it is half-done, as mentioned).

But your knowledge on the inner workings of the TCP layer in the C++ SDK would be invaluable! Particularly in relation to this earlier comment of mine

[gmarcosb]

Responding to your comment

Matter C++ keeps around "active sessions", effectively to be reused (I guess this is per spec, reading your quote from the spec) - when a command is sent, it checks to see if there's an active session (TCP or UDP). If there is, it reuses; if not, it re-establishes with CASE

The way TCP is implemented (which I'm guessing is the Nodes MAY choose to remove the secure session when the connection goes down) is that when the TCP connection is detected to be closed, it collects & disposes of the secure session (i.e. MarkForEviction) & has to re-establish CASE.

But when it doesn't detect it (this happens sometimes with sockets, peer closes & no callback), then it actually just re-connects TCP & re-establishes CASE & doesn't mark the secure connection for eviction

I don't really see any reason for the former (which I think is what you're suggesting), i.e. seems silly to mark secure sessions for eviction that weren't explicitly done so by caller; if TCP connection disappears, we just re-establish (i.e. consistently do the latter)

[gmarcosb]

Re: Opinionated, no problem, would actually appreciate that as I'm clueless about rust 🤣 I'll rust-ify what's done in C++ (modulo the change discussed above about not marking sessions for eviction), and you can guide me towards where you think it should go

[ivmarkov]

In reply to this comment of yours:

Where I'm struggling with is the "network identity" of a session, which we also have here.

For UDP (and BTP) it is easy (kinda) because the session network identity is equal to the remote address (IP + port) of the peer. Since we always use UDP bind and never use UDP connect that's good enough (and the sent UDP packet always have as our source port the actual Matter UDP port; for source IP address it is bit... less well defined especially if we bind to 0::0, but OK we can squint about that).

With TCP, we have the problem that if we "just" use TCP connect, the other peer would see an ephemeral port as our source TCP port. That might or might not be a problem for the other peer. For one, if it wants to re-use this very same TCP session that we established with connect to initiate a new exchange on it, it might really want to see as our TCP port exactly port 5540 (the TCP Matter impl should use that same 5540 port which is used for UDP, right?) as the "source" port, which is not the case with a straightforward TCP "connect". That's why I was mentioning the bind-before-connect trick from the CloudFlare blog.

EDIT: Updated the links.

[gmarcosb]

Ahh good point, I was wondering about the incoming connection - but does it matter? i.e. isn't the address all that matters, when looking up the existing session to use we just use IP, not port? Because there's a layer above the TCP connections (the SessionManager), if we find an existing session there to the IP address (at that point port is irrelevant), it can figure out whether it has an existing TCP connection (regardless of port) or whether it needs to establish one [in the case where the TCP connection dropped]

That's ~how the C++ version is implemented; the SessionManager keeps active sessions, and is able to create/re-use an existing session based on IP; the underlying layer is then what checks whether it's going to go through UDP, or needs to establish/re-establish a TCP connection

[ivmarkov]

i.e. isn't the address all that matters, when looking up the existing session to use we just use IP, not port? Because there's a layer above the TCP connections (the SessionManager), if we find an existing session there to the IP address (at that point port is irrelevant)

That sounds wrong. For one, that would not allow running two Matter instances on a single IP, and I don't see why that would be prohibited, given that Matter - just like any other tcp/udp service - can run on a non-standard port. The concrete port (be it 5540 or another one) is communicated over mDNS as well.