revert Merge pull request 'Service: Sockets: Fix busy-waiting CPU starvation and Close/Socket race conditions' (#100) from fix-socket-performance-and-crashes into main
Reviewed-on: https://git.citron-emu.org/Citron/Emulator/pulls/100
- Replace socket option assertion failures with proper error returns
- Add WSAENOPROTOOPT/ENOPROTOOPT error handling
- Fix LINGER and option value size validation
- Add Network::Errno::OTHER translation
- Implement basic Nex service stub for error code 2306-0520
Fixes crashes in Minecraft and other games when encountering unsupported
socket operations or attempting to use Nintendo's online services.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Major networking enhancements to improve multiplayer performance and
reduce desync issues in games like Mario Kart 8 Deluxe:
Network Performance:
- Add socket connection pooling in BSD service to reduce overhead
- Implement unreliable packet delivery for latency-sensitive game data
- Add packet reliability control for both ProxyPacket and LDNPacket
- Use ENET_PACKET_FLAG_UNSEQUENCED for small UDP packets (<1200 bytes)
Monitoring & Debugging:
- Add PacketStatistics struct to track sent/received/dropped packets
- Enhanced logging for proxy packet handling and socket lifecycle
- Periodic stats logging every 100 packets for diagnostics
Configuration:
- Update lobby_api_url and web_api_url to https://api.ynet-fun.xyz
- Add lobby API URL configuration support
Socket Management:
- Implement SocketPoolKey for efficient socket reuse
- Store domain/type/protocol info in FileDescriptor
- Max pool size limit (8 sockets per type) to prevent memory bloat
- Return closed sockets to pool when room is still connected
Protocol Updates:
- Add 'reliable' field to ProxyPacket and LDNPacket structures
- Update room.cpp packet handlers to respect reliability flags
- Maintain backward compatibility with default reliable=true
These changes significantly reduce packet latency for real-time game
traffic while maintaining reliability for control packets.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Initialize PollFD.revents field to prevent assertion failures when
copying from read buffer. The assertion was failing because revents
contained uninitialized data from the buffer.
Thanks to Dr.Stug for providing the logs that identified this issue.
Fixes assertion failure at core\hle\service\sockets\bsd.cpp:564
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Changes:
- Add validation in BSD::SendToImpl to check for empty address buffers on
datagram sockets and return EINVAL instead of passing nullptr to sendto()
- Add null pointer check in ProxySocket::SendTo to prevent dereferencing
nullptr address parameters
- Improve error logging to help identify socket configuration issues
Fixes: Socket operation errors in HDR multiplayer sessions
Signed-off-by: Zephyron <zephyron@citron-emu.org>
- Accept SockAddrIn len in [6, sizeof] and warn instead of asserting to handle libnx/SSBU quirks
- Ensure TranslateFromSockAddrIn sets sin_port via htons(uint16_t) for consistent network byte-order
- Prevents assertion crashes and reduces “Broken pipe” error spam observed in Frozen's SSBU logs
Signed-off-by: Zephyron <zephyron@citron-emu.org>
- Add Unknown39 and Unknown40 functions to BSD service for [20.0.0+]
- Implement bsd:nu service with ISfUserService and ISfAssignedNetworkInterfaceService
- Add dns:priv and ethc:c/ethc:i service stubs
- Update CMakeLists.txt to include new socket service files
- All new functions include basic stub implementations following existing patterns
This completes the socket services implementation based on switchbrew.org documentation.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Mark ResultNotImplemented and ResultNsdNotInitialized with
[[maybe_unused]] to avoid compiler warnings.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Adds implementations for missing nsd:u and nsd:a services
as documented in SwitchBrew. This includes:
- Defining necessary data structures (Url, SettingName, DeviceId, Fqdn,
NasServiceSetting, NasServiceName, SaveData, TestParameter, DeleteMode,
ImportMode) in nsd.cpp.
- Adding declarations for new service methods to nsd.h.
- Implementing basic stub logic for each new service method in nsd.cpp,
including logging, returning default success/error codes, and handling
output buffers where applicable.
- Implementing checks for nsd:a specific functions using a new
IsNsdA() helper.
- Updating the copyright year in nsd.h.
This provides a complete interface for the nsd service, allowing
further development and reducing unknown service calls.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Adds implementations for missing `sfdnsres` (nn::socket::resolver::IResolver) service functions and corrects command ID mappings to align with Switchbrew documentation.
Key changes:
- Implemented stubs for the following `sfdnsres` functions:
- `SetDnsAddresses` (Cmd 0)
- `GetDnsAddressList` (Cmd 1)
- `GetHostByAddrRequest` (Cmd 4, deprecated)
- `GetHostStringError` (Cmd 5)
- `CancelRequest` (Cmd 7)
- `GetOptions` (Cmd 9)
- `GetAddrInfoRequestRaw` (Cmd 11)
- Updated the command registration table in the `SFDNSRES` constructor to use correct Switchbrew command IDs and map them to the appropriate existing or new (stubbed) implementations.
- Retained and stubbed `GetNameInfoRequest` and `GetNameInfoRequestWithOptions` with placeholder IDs, as they were present in the previous command table.
- Corrected usage of `GetAddrInfoError` constants in stubs to use valid members (e.g., `GetAddrInfoError::AGAIN` instead of a non-standard `INTERNAL`).
This significantly expands the implemented interface for the `sfdnsres` service, bringing it closer to the documented functionality and resolving related compilation errors.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Adds implementations for all `bsdcfg` (aliased as `ifcfg`) service functions as listed in the existing codebase and supplemented by Switchbrew documentation.
The following functions have been added to the `BSDCFG` service:
- `SetIfUp` (Cmd 0)
- `SetIfUpWithEvent` (Cmd 1)
- `CancelIf` (Cmd 2)
- `SetIfDown` (Cmd 3)
- `GetIfState` (Cmd 4)
- `DhcpRenew` (Cmd 5)
- `AddStaticArpEntry` (Cmd 6)
- `RemoveArpEntry` (Cmd 7)
- `LookupArpEntry` (Cmd 8)
- `LookupArpEntry2` (Cmd 9)
- `ClearArpEntries` (Cmd 10)
- `ClearArpEntries2` (Cmd 11)
- `PrintArpEntries` (Cmd 12)
- `Unknown13` (Cmd 13)
- `Unknown14` (Cmd 14)
- `Unknown15` (Cmd 15)
These functions are initially stubbed to log a warning and return `EOPNOTSUPP`.
Command handlers have been updated in the `BSDCFG` constructor.
Additionally, this commit corrects the logging category in these new `BSDCFG` stubs from an undefined `Service_BSDCFG` to the existing `Service` category, resolving compilation errors.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Adds implementations for several previously unimplemented BSD socket service functions, as documented in Switchbrew. REF: https://switchbrew.org/wiki/Sockets_services#bsd:u.2C_bsd:s.2C_bsd:a
The following functions have been added to the `bsd:u`, `bsd:s`, and `bsd:a` services:
* `SocketExempt` (Cmd 3)
* `Open` (Cmd 4)
* `Sysctl` (Cmd 7)
* `Ioctl` (Cmd 19)
* `ShutdownAllSockets` (Cmd 23)
* `GetResourceStatistics` (Cmd 28)
* `RecvMMsg` (Cmd 29)
* `SendMMsg` (Cmd 30)
* `RegisterResourceStatisticsName` (Cmd 32)
* `RegisterClientShared` (Cmd 33) (replaces the placeholder `Initialize2`)
* `GetSocketStatistics` (Cmd 34)
* `NifIoctl` (Cmd 35)
* `SetThreadCoreMask` (Cmd 200)
* `GetThreadCoreMask` (Cmd 201)
These functions are initially set to log a warning and return an appropriate error code (typically `EOPNOTSUPP` or `ENOTTY`), or success in the case of registration-type functions.
The command handlers have been registered in the BSD service constructor.
This resolves various compilation errors encountered during the implementation process related to IPC response generation and enum usage.
Signed-off-by: Zephyron <zephyron@citron-emu.org>
Add support for the CONNREFUSED Errno.
Without this Connect() will return SUCCESS when a connection is refused, instead of an error code. This causes code, that relies on the result of Connect() being SUCCESS, to execute when it shouldn't.
- On Unix, this would previously kill the Yuzu process with SIGPIPE.
Send MSG_NOSIGNAL to opt out of this.
- Add support for the proper error code in this situation, EPIPE.
- Windows has nonstandard behavior in this situation; translate it to
the standard behavior. Kind of pointless, but isn't it nice to be
correct?
- Add missing virtual destructor on `SSLBackend`.
- On Windows, filter out `POLLWRBAND` (one of the new flags added) when
calling `WSAPoll`, because despite the constant being defined on
Windows, passing it calls `WSAPoll` to yield `EINVAL`.
- Reduce OpenSSL version requirement to satisfy CI; I haven't tested
whether it actually builds (or runs) against 1.1.1, but if not, I'll
figure it out.
- Change an instance of memcpy to memmove, even though the arguments
cannot overlap, to avoid a [strange GCC
error](https://github.com/yuzu-emu/yuzu/pull/10912#issuecomment-1606283351).
This implements some missing network APIs including a large chunk of the SSL
service, enough for Mario Maker (with an appropriate mod applied) to connect to
the fan server [Open Course World](https://opencourse.world/).
Connecting to first-party servers is out of scope of this PR and is a
minefield I'd rather not step into.
## TLS
TLS is implemented with multiple backends depending on the system's 'native'
TLS library. Currently there are two backends: Schannel for Windows, and
OpenSSL for Linux. (In reality Linux is a bit of a free-for-all where there's
no one 'native' library, but OpenSSL is the closest it gets.) On macOS the
'native' library is SecureTransport but that isn't implemented in this PR.
(Instead, all non-Windows OSes will use OpenSSL unless disabled with
`-DENABLE_OPENSSL=OFF`.)
Why have multiple backends instead of just using a single library, especially
given that Yuzu already embeds mbedtls for cryptographic algorithms? Well, I
tried implementing this on mbedtls first, but the problem is TLS policies -
mainly trusted certificate policies, and to a lesser extent trusted algorithms,
SSL versions, etc.
...In practice, the chance that someone is going to conduct a man-in-the-middle
attack on a third-party game server is pretty low, but I'm a security nerd so I
like to do the right security things.
My base assumption is that we want to use the host system's TLS policies. An
alternative would be to more closely emulate the Switch's TLS implementation
(which is based on NSS). But for one thing, I don't feel like reverse
engineering it. And I'd argue that for third-party servers such as Open Course
World, it's theoretically preferable to use the system's policies rather than
the Switch's, for two reasons
1. Someday the Switch will stop being updated, and the trusted cert list,
algorithms, etc. will start to go stale, but users will still want to
connect to third-party servers, and there's no reason they shouldn't have
up-to-date security when doing so. At that point, homebrew users on actual
hardware may patch the TLS implementation, but for emulators it's simpler to
just use the host's stack.
2. Also, it's good to respect any custom certificate policies the user may have
added systemwide. For example, they may have added custom trusted CAs in
order to use TLS debugging tools or pass through corporate MitM middleboxes.
Or they may have removed some CAs that are normally trusted out of paranoia.
Note that this policy wouldn't work as-is for connecting to first-party
servers, because some of them serve certificates based on Nintendo's own CA
rather than a publicly trusted one. However, this could probably be solved
easily by using appropriate APIs to adding Nintendo's CA as an alternate
trusted cert for Yuzu's connections. That is not implemented in this PR
because, again, first-party servers are out of scope.
(If anything I'd rather have an option to _block_ connections to Nintendo
servers, but that's not implemented here.)
To use the host's TLS policies, there are three theoretical options:
a) Import the host's trusted certificate list into a cross-platform TLS
library (presumably mbedtls).
b) Use the native TLS library to verify certificates but use a cross-platform
TLS library for everything else.
c) Use the native TLS library for everything.
Two problems with option a). First, importing the trusted certificate list at
minimum requires a bunch of platform-specific code, which mbedtls does not have
built in. Interestingly, OpenSSL recently gained the ability to import the
Windows certificate trust store... but that leads to the second problem, which
is that a list of trusted certificates is [not expressive
enough](https://bugs.archlinux.org/task/41909) to express a modern certificate
trust policy. For example, Windows has the concept of [explicitly distrusted
certificates](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn265983(v=ws.11)),
and macOS requires Certificate Transparency validation for some certificates
with complex rules for when it's required.
Option b) (using native library just to verify certs) is probably feasible, but
it would miss aspects of TLS policy other than trusted certs (like allowed
algorithms), and in any case it might well require writing more code, not less,
compared to using the native library for everything.
So I ended up at option c), using the native library for everything.
What I'd *really* prefer would be to use a third-party library that does option
c) for me. Rust has a good library for this,
[native-tls](https://docs.rs/native-tls/latest/native_tls/). I did search, but
I couldn't find a good option in the C or C++ ecosystem, at least not any that
wasn't part of some much larger framework. I was surprised - isn't this a
pretty common use case? Well, many applications only need TLS for HTTPS, and they can
use libcurl, which has a TLS abstraction layer internally but doesn't expose
it. Other applications only support a single TLS library, or use one of the
aforementioned larger frameworks, or are platform-specific to begin with, or of
course are written in a non-C/C++ language, most of which have some canonical
choice for TLS. But there are also many applications that have a set of TLS
backends just like this; it's just that nobody has gone ahead and abstracted
the pattern into a library, at least not a widespread one.
Amusingly, there is one TLS abstraction layer that Yuzu already bundles: the
one in ffmpeg. But it is missing some features that would be needed to use it
here (like reusing an existing socket rather than managing the socket itself).
Though, that does mean that the wiki's build instructions for Linux (and macOS
for some reason?) already recommend installing OpenSSL, so no need to update
those.
## Other APIs implemented
- Sockets:
- GetSockOpt(`SO_ERROR`)
- SetSockOpt(`SO_NOSIGPIPE`) (stub, I have no idea what this does on Switch)
- `DuplicateSocket` (because the SSL sysmodule calls it internally)
- More `PollEvents` values
- NSD:
- `Resolve` and `ResolveEx` (stub, good enough for Open Course World and
probably most third-party servers, but not first-party)
- SFDNSRES:
- `GetHostByNameRequest` and `GetHostByNameRequestWithOptions`
- `ResolverSetOptionRequest` (stub)
## Fixes
- Parts of the socket code were previously allocating a `sockaddr` object on
the stack when calling functions that take a `sockaddr*` (e.g. `accept`).
This might seem like the right thing to do to avoid illegal aliasing, but in
fact `sockaddr` is not guaranteed to be large enough to hold any particular
type of address, only the header. This worked in practice because in
practice `sockaddr` is the same size as `sockaddr_in`, but it's not how the
API is meant to be used. I changed this to allocate an `sockaddr_in` on the
stack and `reinterpret_cast` it. I could try to do something cleverer with
`aligned_storage`, but casting is the idiomatic way to use these particular
APIs, so it's really the system's responsibility to avoid any aliasing
issues.
- I rewrote most of the `GetAddrInfoRequest[WithOptions]` implementation. The
old implementation invoked the host's getaddrinfo directly from sfdnsres.cpp,
and directly passed through the host's socket type, protocol, etc. values
rather than looking up the corresponding constants on the Switch. To be
fair, these constants don't tend to actually vary across systems, but
still... I added a wrapper for `getaddrinfo` in
`internal_network/network.cpp` similar to the ones for other socket APIs, and
changed the `GetAddrInfoRequest` implementation to use it. While I was at
it, I rewrote the serialization to use the same approach I used to implement
`GetHostByNameRequest`, because it reduces the number of size calculations.
While doing so I removed `AF_INET6` support because the Switch doesn't
support IPv6; it might be nice to support IPv6 anyway, but that would have to
apply to all of the socket APIs.
I also corrected the IPC wrappers for `GetAddrInfoRequest` and
`GetAddrInfoRequestWithOptions` based on reverse engineering and hardware
testing. Every call to `GetAddrInfoRequestWithOptions` returns *four*
different error codes (IPC status, getaddrinfo error code, netdb error code,
and errno), and `GetAddrInfoRequest` returns three of those but in a
different order, and it doesn't really matter but the existing implementation
was a bit off, as I discovered while testing `GetHostByNameRequest`.
- The new serialization code is based on two simple helper functions:
```cpp
template <typename T> static void Append(std::vector<u8>& vec, T t);
void AppendNulTerminated(std::vector<u8>& vec, std::string_view str);
```
I was thinking there must be existing functions somewhere that assist with
serialization/deserialization of binary data, but all I could find was the
helper methods in `IOFile` and `HLERequestContext`, not anything that could
be used with a generic byte buffer. If I'm not missing something, then
maybe I should move the above functions to a new header in `common`...
right now they're just sitting in `sfdnsres.cpp` where they're used.
- Not a fix, but `SocketBase::Recv`/`Send` is changed to use `std::span<u8>`
rather than `std::vector<u8>&` to avoid needing to copy the data to/from a
vector when those methods are called from the TLS implementation.
