just to be able to read user packets from TAP
split the UDP and TUN listeners into separate event queues
added some notes in tuntap-windows (mostly gutting it since we do a lot of the stuff ourselves)
need to be able to queue up a TUN read/write at each tick
then finish dealing with it in the main event loop
which is damn near impossible to do along with unix-style asio
that waits for data to appear/disappear before signalling
the native async event system on windows
is _not_ very good at getting external events
(i.e. we receive data, but we don't get any indication
that this ever happened)
find some place in the C code to place the worker thread procedure
until such time that michael presents the new thread pool class
fix unix
get a new event port each time and delet in the event loop after use
msys2 grabs its reactos sdk headers straight out of git
most cross-compilers use the versioned releases (v6 as of last week)
huh. for once setting the windows version macros doesn't break anything.
up next: debugging the windows client code
stretch goal: prototype hosting a full masternode on Windows Server (still _highly_ experimental when it _does_ appear)
add win32 tun glue, fix llarp timebase
(In fact, _both_ of these are guaranteed to exist on their respective platforms.)
also, tuntap is now wired up to the windows port
old hard-coded inline asm is still included if requested.
-rick
nb: is a vector of eight floats not the same layout as a simple linear array of same? (Aside from the alignment requirements)
netbsd-family build fixes, also - the AVX2 codepaths are _compiler-specific_, they use features _exclusive_ to gcc and clang
SunOS build works, with a few issues:
- no tuntap debugging on Solaris? (TUNSDEBUG ioctl missing)
- regular socket ioctls are not pulled in with #include <sys/ioctl.h>
even though they're included at the bottom of same (filio.h,
sockio.h)
- no named threads in any libre fork of solaris
-despair86 (rick)
sun patch
- updated CMake build script
- builds with Microsoft C++ 19.1x. such builds require Windows 8.1 or later
unless you have the .NET Server 2003-toolset (v141_xp)
- windows port requires a C++17 compiler since cpp17::filesystem is POSIX-only
- HAVE_CXX17_FILESYSTEM manual toggle in CMake. You must manually specify where
std::[experimental::]filesystem is defined in LDFLAGS or CMAKE_x_LINKER_FLAGS.
- IPv6 support can be added at any time, and the windows sdk still has that
inline getaddrinfo(3) if it can't find a suitable IPv6 stack.
- inline code for mingw-w64: there's a few bits and pieces still missing simply because
mingw-w64 derives its windows sdk from wine and reactos, and then writing all the newer
stuff into it by hand straight from the MSDN manpages.
- misc. C++11 stuff (nullptr and friends)
- Internal file handling code takes UTF-8 or plain 8-bit text, NTFS is UTF-16, so
std::filesystem::path::c_str() is wchar_t. That's no good unless you first
call std::filesystem::path::string().
- implemented getifaddrs(3) and if_nametoindex(3) on top of GetAdapters[Info|Addresses](2).
- updated readme with new info
BONUS: may implement Solaris/illumos IOCP someday...
-despair86
