-
Notifications
You must be signed in to change notification settings - Fork 447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
smoltcp as Redox network stack #50
Comments
Correct.
What I want to do is to extract the type definitions in Then, I would add yet another crate, let's say Then, protocols could be implemented on top of
Traceroute. Just add them, it's not a huge cost, and we have socket features now anyway. The reduction in potential data leakage is sweet.
I agree. I actually think that smoltcp should always use maps for dispatch. Except, on bare metal without allocation it should be a linearized O(n) map like the one currently used in SliceArpCache, and with allocation it should just be a BTreeMap. So there'll be a ManagedMap. This means that port uniqueness / ephemeral generation will become trivial.
Sure. A trivial PR. I haven't added it despite it being required by RFC 1122 simply because I had no use for it.
It's fully equivalent to the BSD sockets. Open many sockets on the same port in the LISTEN state, that's your backlog. What smolnetd currently does is equivalent to backlog of 1.
That's a bug (and a release blocker). #25
Sure, I'm looking into #18 now, then it'll be that. No big issues.
Sounds like good functionality for SocketSet, perhaps even implemented similarly to our tracking of API consumer caused state changes.
This can be implemented using the same kind of state tracking as your previous item. Socket went to closed after the I'd prefer if you created a smoltcp issue for every unique item here, extracting my suggestions, and then we could continue the discussion over there. |
Can this be closed? smoltcp is the redox network stack since redox-os/netstack#4. There are still some relevant issues that @batonius mentions that are still not yet implemented, but maybe they should be split out into separate issues? |
This is split out into #55.
This is being handled in #75.
This was done in #64.
This is by design since multiple sockets on the same local port is how smoltcp implements backlog for streaming sockets. The POSIX-like behavior may be provided separately by an upper layer if necessary, I'll merge a PR implementing it but see no urgent need to add it.
This was done in #58.
This was handled in #68. To summarize, yes, this issue can be closed, and everything is split out already, no need to do it. |
Context: I've been working on reimplementing Redox's network stack with smoltcp, and it looks good so far. In the process, I've come up with a number of issues/ideas/proposals I want to discuss.
New features:
loopback
example solves this by using a loopback device, which is not an option for smolnetd. I think smoltcp should support several devices, each with several subnets assigned to them. This way we would be able to add loopback interface by adding a loopback device with 127.0.0.1/8 assigned to it.dhcpd
daemon for this.ping
able to work without suid, but I'm not sure if they're useful for anything besidesping
. Right now Redox hasicmpd
daemon.bind
is called with port == 0, so smolnetd implements its own ports set. I think some form of it should be integrated into smoltcp itself, probably as part of the packet dispatch effort.Improvements:
TcpStream
andUdpSocket
.Optimizations:
EthernetInterface::poll
produced some kind of list of the sockets which state changed during the call.SocketSet::prune
after eachSocketSet::release
to free sockets, which means iteration over all the sockets in the set. I understand we can't free sockets inrelease
because TCP sockets require shutdown, but maybe we should initiate the shutdown inrelease
and then haveSocketSet
threat closed TCP sockets withrefs
== 0 as empty?@whitequark Of all the issues, I think loopback interface is the most pressing right now, so I'd like to know what you think would be the best way to approach it.
cc @little-dude , @jackpot51
The text was updated successfully, but these errors were encountered: