cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<re_irc>
<chrysn (@chrysn:matrix.org)> lulf, what was the matter with the UDP async traits? I was about to implement them when I fou d them gone in 0.2.
<re_irc>
<chrysn (@chrysn:matrix.org)> In embedded-nal-std I found no issues with them.
<re_irc>
... tx/rx of UDP send/recv concurrently. For -std it's a bit simpler because it's all done by the OS, but IMHO we should try to model the traits so they work for the bare metal use case. Sorry it was just pulled out that quickly though, but thought it was better to remove before they got to be in use (seems you were quicker than me heh)
<re_irc>
<chrysn (@chrysn:matrix.org)> separate rx/tx sounds sensible, thanks. will read through the discussions to see whether to add something.
<re_irc>
<chrysn (@chrysn:matrix.org)> the problem would not have arisen on my platform (riot), but that's like half way to supporting std (although forcing std there makes no sense imo).
<re_irc>
<lulf> Ivan from Espressif is probably interested in discussion UDP traits as well if you have some ideas (I'd also like that, just don't have it on my near-future agenda)
<re_irc>
<lulf> * discussing
<re_irc>
<chrysn (@chrysn:matrix.org)> Since this is sharing the issue tracker (and, admittedly, many issues, so that on its own is a good thing) with embedded-nal, could we set up a label for "async" issues and PRs?
<re_irc>
<eldruin> Sure, I'll do that
<re_irc>
<eldruin> it's difficult to draw the line in embedded-nal :D
<re_irc>
<eldruin> feel free to propose issues for the label
<re_irc>
<chrysn (@chrysn:matrix.org)> How should we generally go about the concurrently-awaiting-multiple-things-from-the-same-stack issue? I've always liked the part of having exclusive access to the stack, but indeed for async it doesn't work well -- we'd need the exclusive access at poll time and not at invocation time.
<re_irc>
<chrysn (@chrysn:matrix.org)> I'm trying to reconcile my vague dislike for the socked-directed API ("no stack, just sockets") with my equally vague gut feeling that for an async API, the stack reference would not be necessary as long as we allow the stack and its sockets to all be not Send.
<re_irc>
<chrysn (@chrysn:matrix.org)> But all I come up with is that in situations where I'd needed it (eg. sending UDP packets from an interrupt, where you don't just need to pass in the socket) the acquisition of the stack would necessarily be fallible, just as in a socket-oriented version the internal (shared-bus like) acquisition of the socket would be fallible, so that's OK-ish.
<re_irc>
The bad part is still that we'd have to manually wrap the socket into something shared-bus-ish, and that's not zero-cost compared to a hypothetical nb-style executor where the stack would be passed exclusively to each "future" that is "polled".
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<re_irc>
<dirbaio> yep "concurrently-awaiting-multiple-things-from-the-same-stack" is the reason the new async tcp traits don't have a "stack" objet
<re_irc>
<dirbaio> * object
<re_irc>
<dirbaio> instead, internally the sockets can have a "&Stack" or whatever
<re_irc>
<dirbaio> so the impl manages the "stack sharing"
<re_irc>
<dirbaio> if the sharing is done with RefCell, the sockets are "!Send"
<re_irc>
if the sharing is done with a critical section Mutex, the sockets can be "Send"
<re_irc>
<dirbaio> for sending from IRQ, either use an impl that's "Send", or use a Channel to send the data to main
<re_irc>
<dirbaio> +then send it from there
<re_irc>
<dirbaio> anyway, with async it's much rarer to run code on IRQ handlers, because you can await things from the main thread instead.
<re_irc>
<dirbaio> seems whatever we find works for async, would also work for non-async nonblocking
<re_irc>
<dirbaio> changing "async fn" to "fn -> Result<.., Error>" where "Error" can be "WouldBlock"
<re_irc>
<dirbaio> i'm not a fan of the typestates BTW
<re_irc>
<dirbaio> in the new async "TcpConnect" trait, you only get the socket after connect was successful (instead of first creating the socket, then telling it to connect), so that no typestates are needed :)
causal has joined #rust-embedded
<re_irc>
<chrysn (@chrysn:matrix.org)> But that _is_ type stating -- the better it's done, the less you notice :-)
<re_irc>
(Admittedly people might disagree on the definition -- at any rate, it is what makes me happy and would make me close that typestating issue).
<re_irc>
<dirbaio> 🤣🤣
<re_irc>
<dirbaio> true
<re_irc>
<dirbaio> it's not the "bad" typestating like "Socket<Disconnected>, Socket<Connected>"
<re_irc>
<dirbaio> that
<re_irc>
<dirbaio> * that's the one that sucks, it makes it impossible to own one of these because it constantly keeps shifting type from under you
<re_irc>
<luojia65> what will happen if chip would identify some kind of read only file system in rom code
<Lumpio->
I'd like to know how a Socket<Connected> would work when it can become disconnected at any point in time
dc740 has joined #rust-embedded
brazuca has quit [Quit: Client closed]
<re_irc>
<dirbaio> chrysn: seems very complex 😅
<re_irc>
<dirbaio> complex in general I mean, not particularly about the types
<re_irc>
<chrysn (@chrysn:matrix.org)> If that is to TCP, that'll grow (considering that will grow bind and accept methods); if it's to sync/nb UDP, the last third introduces functionality from #40/#41 that may be left for later.
<re_irc>
<chrysn (@chrysn:matrix.org)> Anything in particular that you'd rather have simpler?
<re_irc>
<chrysn (@chrysn:matrix.org)> (Also, TCP has it easy because there is "embedded_io::asynch::{Read, Write}", where no such traits exist for non-streaming sockets)
<re_irc>
<dirbaio> not sure how/if to simplify it though, I see the problem 😓
<re_irc>
<dirbaio> in TCP, after doing connect/listen/accept, you get the same type (that's just impl Read+Write)
<re_irc>
<chrysn (@chrysn:matrix.org)> Mh, I might manage to make it so that there is an accept-ish method, which then also produces a ConnectedUdp -- for those cases that are strictly client-server.
<re_irc>
<dirbaio> but in UDP depending on how you opened the socket, you have socketaddrs or not on send/recv :S
<re_irc>
<chrysn (@chrysn:matrix.org)> (As a detail on the side, it should be well possible to even implement that platform independently on a bound socket, although I bet the OS does it better).
<re_irc>
<chrysn (@chrysn:matrix.org)> Yes, thus the traits. But if "actually I just want to send and receive like in TCP" is such a common use case as I'd interpret your "in TCP you get the same type" comment, that can be made possible.
<re_irc>
<chrysn (@chrysn:matrix.org)> It'd just be yet another way into sockets, and I'm not sure that there are too many cases where that's really what you want.
<re_irc>
<dirbaio> recv's can easily be unified: always return the socketaddrs
<re_irc>
<chrysn (@chrysn:matrix.org)> (At least judging from the CoAP implementers' point of view, where most people who do it that way wind up with broken implementations).
<re_irc>
<chrysn (@chrysn:matrix.org)> So could be sends (it'd just be ignored), but would that make a better API?
<re_irc>
<dirbaio> yeah for sends always requiring the socketaddrs would be annoying
<re_irc>
<dirbaio> :S
<re_irc>
<chrysn (@chrysn:matrix.org)> maybe even for recv -- if you have a connected socket, "let _, _, data = sock.recv().await.unwrap();" would be a regular occurrence.
<re_irc>
<dirbaio> send could either ignore them, or return an error if they don't match
<re_irc>
<chrysn (@chrysn:matrix.org)> Either way, it'd be shoving a lot of addresses around that 1/3 of users don't care about.
<re_irc>
<dirbaio> perhaps only have 2 socket kinds?
<re_irc>
<chrysn (@chrysn:matrix.org)> Maybe reduce it to two cases, one for connected, one for the other?
<re_irc>
<dirbaio> lol
<re_irc>
<dirbaio> exactlt, tha
<re_irc>
<dirbaio> * that
<re_irc>
<chrysn (@chrysn:matrix.org)> Mh, that might work; I'll give it a try to see what the API would look like.
<re_irc>
<dirbaio> - socket with fixed (src addr+port, dst addr+port). send/recv only require &[u8]
<re_irc>
- all other sockets (possibly fixed, possibly wildcard src/dst addr+port). send+recv require (addr, addr, &[u8])
<re_irc>
<chrysn (@chrysn:matrix.org)> It'd still be some overhead -- POSIX implementations would always need use PKTINFO -- but maybe by setting it up right that can be optimized out.
<re_irc>
<dirbaio> so for clients you'd use the 1st, for servers (or advanced stuff, like a client that wants to talk to lots of servers) you'd use the 2nd
<re_irc>
<chrysn (@chrysn:matrix.org)> Implementations would have the option whether or not to set up different output types for bind_single and bind_multiple, and if they go the extra length, some code paths would be open to pruning in LTO.
<re_irc>
<dirbaio> ah because recvfrom only returns the src (their) addr, not ours?
<re_irc>
<dirbaio> perhaps the impl can return 0.0.0.0 if our addr is unknown?
<re_irc>
<dirbaio> +so it can use plain old recvfrom?
<re_irc>
<dirbaio> and sending with src addr 0.0.0.0 would mean "pick any", so could use plain old sendto
<re_irc>
<chrysn (@chrysn:matrix.org)> If there are 2 rather than 3 types, the server won't know whether the client needs the local address or not.
<re_irc>
<chrysn (@chrysn:matrix.org)> The 2-trait API has a few nice aspects for the backend implementer, but the user of what used to be BoundUdp (the middle version) will need to cooperate to make that possible (i.e. always round-trip the local address). All in all, I think that's an improvement.
<re_irc>
<dirbaio> yea I'm not sure if the 2-trait api is better
<re_irc>
<dirbaio> what's the use cases for "UnboundUdp"?
<re_irc>
<dirbaio> maybe we can simply not have it?
<re_irc>
<chrysn (@chrysn:matrix.org)> The use case is that for some protocols you need to be in control of which address you send from.
<re_irc>
<chrysn (@chrysn:matrix.org)> This is even before multicast comes in -- just binding to "[::]:5683" and using recvfrom / sendto is a recipe for breaking the CoAP protocol, because people test it on machines with only a single IP address, and once a production machine gets two, suddenly requests start failing.
<re_irc>
<dirbaio> but that can be achieved with BoundUdp by binding to "1.2.3.4:5683"
<re_irc>
<dirbaio> so you only get packets for one IP and you always reply from that one
<re_irc>
<dirbaio> and if you want to listen on 2 addrs then create 2 sockets
<re_irc>
<dirbaio> plus sendto already picks the right src addr if the peer is only reachable with one of our src addrs
<re_irc>
<chrysn (@chrysn:matrix.org)> Yes, but you don't always _want_ to bind to a specific address, because:
<re_irc>
<chrysn (@chrysn:matrix.org)> - You'd need to enumerate the OS's interfaces (no traits for that in embedded-nal)
<re_irc>
- Interfaces can be hotplugged, and if so you need to react to OS's hotplug events
<re_irc>
- You need memory proportional to the number of interfaces
<re_irc>
<chrysn (@chrysn:matrix.org)> dirbaio: But that's not always the case. In a v6 scenario, you can easily have 2-3 routable addresses per prefix, and when multihomed, multiple prefixes -- and global addresses are reachable over all of them.
<re_irc>
<dirbaio> is this a common problem in _embedded devices_ though?
<re_irc>
<chrysn (@chrysn:matrix.org)> Yes; multiple prefixes are an explicitly useful thing for reliability.
<re_irc>
<dirbaio> smoltcp doesn't even support multiple interfaces
<re_irc>
<dirbaio> also AT-command based stacks don't usually support seeing/setting the local addr
<re_irc>
<chrysn (@chrysn:matrix.org)> (AIU even Thread who are in the home market at some point recommend having at least 2 BRs, and at least in generic 6LoWPAN these have different prefixes)
<re_irc>
<chrysn (@chrysn:matrix.org)> Well border routers can be implemented as smaller-than-Linux devices, and these definitely have >=2 interfaces. (Currently many BRs are OpenWRT, but RIOT based ones are perfectly operational too, at least for small networks.)
<re_irc>
<chrysn (@chrysn:matrix.org)> dirbaio: That is indeed an issue -- in the 3-trait version that'd be resolved smoothly, and only need an Option<> around the local address returned at setup time.
<re_irc>
<dirbaio> wow this is cursed
<re_irc>
<dirbaio> the UDP thing in general
<re_irc>
<dirbaio> it's more complex than I thought 😂
<re_irc>
<chrysn (@chrysn:matrix.org)> I haven't even gotten into flow control :-D
<re_irc>
<chrysn (@chrysn:matrix.org)> From some point of view, yes -- but that's also what makes it super powerful.
<re_irc>
<chrysn (@chrysn:matrix.org)> Generally, if TCP works at some place, great, fine, and highly recommended.
<re_irc>
<chrysn (@chrysn:matrix.org)> And it's not all the UDP users that _need_ these features, but those who do generally have good reason for it, and also often sit in the embedded space.
<re_irc>
<chrysn (@chrysn:matrix.org)> A version with the two traits is up now.