For a while they told you open all UDP ports for the Nintendo Switch. Now they just tell you to open 1024 to 65535.

Source for everybody not believing this:

https://en-americas-support.nintendo.com/app/answers/detail/... (Point 4 under "On a PC or smart device")

> The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.

You'd think they'd just admit that and outsource their network-related needs to a company that specializes in that sort of thing.

I respect the prioritization. It doesn't actually need the best web services, it really only needs enough to play Mario kart online.

Interesting! Can you perhaps elaborate a bit more on what you saw at the time, in the sense of why it was so bad (Nintendo lawyers, look away)?

It has been awhile, but from what I remember Nintendo was extremely skimpy with the memory allocated to the TCP stack on the Wii meaning it couldn't open the window up hardly at all and had a tiny bandwidth delay product. This is why updating the system took absolutely forever, even when your local network and the Nintendo servers had ample bandwidth.

Beyond that the servers were also badly implemented and from what I understand they had to call in a third party company to install TCP PEPs[1] in front of the servers to get acceptable performance.

The Wii has ample compute power and memory to max out a Fast Ethernet (100Mbps) port, but due to the design decisions it was barely able to push 1Mbps in real life. This was becoming a problem as system updates were getting larger and the built-in "channel" games were moving beyond NES and SNES ports to actual third party indie titles that sometimes got rather large.

[1] https://en.wikipedia.org/wiki/Performance-enhancing_proxy

A sidenote is that Wii actually ran a separate operating system (nicknamed IOS by the community) in a dedicated ARM processor (Starlet), that was responsible for performing the majority of device input/output, including disk access, internal and external storage, and notably in this case, networking - the TCP/IP stack was implemented entirely there.

Besides running on a weaker CPU, IOS can access (for exclusive use) some of the main system memory, but it was usually about 12-16MB to not starve the actual games running on the main CPU (https://wiibrew.org/wiki/Memory_map), which can help explain why everything except for the actual games was so slow.

Originally, code running on the main PPC CPU could not access directly most of the IO related hardware at all (only GPU/display output and wired controllers - the bluetooth stack was also on IOS AFAIK, but the Wiimote drivers themselves were userspace), so even the Linux ports had to "proxy" some hardware access through the IOS, but later after reverse-engineering the full boot process, people were able to create a replacement IOS that could enable full access through a special register: https://wiibrew.org/wiki/MINI, enabling full-speed Linux ports, and since that functionality is about a decade old now, I would guess that the NetBSD port also takes advantage of that.

> The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.

Innovating on games with multiplayer and then putting in a wifi chip that gives a ping of like 100ms at best seems like orthogonal goals.