As the Windows support has matured, large portions of the Swift ecosystem has become available on Windows. swift-nio provides a wonderful abstraction of the networking APIs and helpers for asynchronous programming that make writing efficient networking programs possible. Since networking is such a common operation these days, it makes sense that one would want to write networking code for their applications.
I'd like to announce that it is now possible to share your networking code written using swift-nio not only on Linux and macOS, but on Windows too! A simple example, here is a screenshot of the NIOEchoServer and NIOEchoClient from the swift-nio repository running on Windows (please ignore the unsightly debugging output):
The changes for this are on github in the swift-nio repository as a pull request, but the changes are not really in an organized state (it is a single ginormous patch) and there are a few places where the changes are not properly guarded. There is work that is needed to clean up the work and create more manageable changes which can be reviewed. Some of this will require a bit of work to adjust the APIs to abstract out details of the underlying system (e.g. there are cases where the underlying C library is expected to provide the BSD sockets API). However, this work demonstrates it is possible to provide the same API surface on all the platforms enabling cross-platform code.
Finally, thanks to @graskind, @lukasa, and @johannesweiss for helping answer in various states of confusion. Their answers helped make this possible.
This is really fantastic work @compnerd! I know it's been a long road and many of the original design decisions in NIO made your life much harder than it needed to be, but you've done an amazing job pushing this far. We're looking forward to continuing to work with you to keep this moving forward andland this in NIO. Not to mention all of the possible exciting work in the form of an IOCP-based EventLoop!
Thanks @lukasa! Fortunately, I think that we should be able to address those design decisions and improve nio in the process!
One of the other cool things is that the new work also enables - the possibility of having NIO backed by alternate networking stacks - perhaps an option to back swift-nio by lwIP?
I think it'll be really great to see a new partner to swift-nio-transport-services in the "alternate networking backends". Especially as we move to a world envisioned in On the road to Swift 6 of Swift running in a wide range of environments, ensuring that NIO can run in those environments gives the Swift ecosystem enormous value. In particular I'm interested in environments further away from the traditional Unix space: while the various Windows options are one, I'm also keeping one eye on WASM as an environment too!
I want to echo everything @lukasa says, this is really fantastic work. Thank you!
I apologise for the POSIX/UNIX centric view of the world that SwiftNIO took, some things you have already fixed, some more we will fix, and when the time (it'll be a while I suspect) for NIO 3 has come we can iron out the vast majority of the wrinkles and delete a bunch of then-deprecated API .
Cheer ! It is a pleasure thanks to your work to build reusable Swift solutions on the three platforms macOS, Linux and Windows. When I code requiring simple TCP/UDP network APIs I currently use BlueSocket which is very simple and works very well on macOS and Linux. Regarding Windows, I would like to have your opinion. Should I replace BlueSocket with NIO? Trying to modify BlueSocket to support Windows? Other solutions? In short, I am looking for the simplicity of BlueSocket and macOS / Linux / Windows compatibility.
There is a fair amount of work yet to be done. Most of the previous work that I had done to add support for Windows for NIO is now pretty out of date as it has been quite a few years. The work never was fully merged, so NIO doesn't properly support Windows yet. Help to finish the work is definitely welcome
There are still a number of other items that I am still working on (SPM is amongst that, but there are still a few more items in the toolchain that also need to be addressed), so my attention is split amongst those items beyond the fact that this is not something that I more as a hobby rather than a paid position so there is also the caveat that other work also intrudes upon my time that I can devote to this.
I would say that overall, getting NIO at parity would be a far more useful endeavour as it unlocks a lot more possibilities. If you need a short term solution, it may be easier to add Windows support to BlueSocket - most of the basic operations functioned quite well in NIO.
Thank you for your advice Saleem. I just finished adding Windows support to BlueSocket and am excited to share my work. Hope this helps with rudimentary TCP/UDP needs on Windows. I can't wait to have SwiftNIO on Windows!
The question is then how could we support you – I think a lot of this work requires quite some expertise, more so if even LLVM gets involved. I would finance a student trainee (2 days/week) to help you (at least for a limited time, say a year), but I do not know how many students are into compiler stuff these days, and if this would be more a burden for you than a real help.
.
:-)