DEV9: Improve speed of TCP connections on the sockets backend

[TheLastRar]

Description of Changes

Increases the number of sent packets that are yet to be acknowledged (from 1 to 64).
Consider the amount of outstanding, yet to be acknowledged, data when determining the max packet size
Fixes incorrect code for handling sequence overflow
Corrects some logs

Rationale behind Changes

The code was over cautious, and was bottlenecking TCP connections, we need more speed
Fixes a (probably very rare?) bug

Suggested Testing Steps

Test networking games that use TCP (mostly server based games)

[TheLastRar]

I'm not sure why the Clang build failed, It built correctly on my branch

[AmyRoxwell]

Doesn't seem to do anything for Monster Hunter 2 Dos, spits same information after coming from a quest with 3+ players:

Master:

Emulog: (not full due to me forgetting to get it oops)

Pr:

Emulog:
emulog.zip

[TheLastRar]

Doesn't seem to do anything for Monster Hunter 2 Dos, spits same information after coming from a quest with 3+ players:

I think I've figured out this issue, it's caused by the following;

1. unsigned long is 32bits on Windows and (typically) 64bits on linux
2. The log message used %d instead of %lu, which expects int, and ignores the upper 32bits of 64bit types
3. FIONREAD, the ioctl, used to get the amount of available data, is unsigned long on windows, but int on linux
4. The available variable wasn't initialised.

On windows, everything is the same size (32bits) and works as expected

On Linux;
available is created with 64bits of uninitialised data
FIONREAD writes 32bits
The condition to print the log reads the full 64bits, and because of the unwritten upper 32bits of available, ends up (sometimes) passing
The log message only reads 32bits, and prints Got a lot of data: 0 (or however much actually is available).

These small differences between platforms are annoying to deal with.

I've opted to zero initialise available, which should fix the issue, the variable is only used for logging, and you've confirmed the game works fine, so the only issue was the incorrect log spam.

Can you test the latest build on this pr to confirm it works

[AmyRoxwell]

Doesn't seem to do anything for Monster Hunter 2 Dos, spits same information after coming from a quest with 3+ players:

I think I've figured out this issue, it's caused by the following;

1. `unsigned long` is 32bits on Windows and (typically) 64bits on linux

2. The log message used `%d` instead of `%lu`, which expects int, and ignores the upper 32bits of 64bit types

3. `FIONREAD`, the `ioctl`, used to get the amount of available data, is `unsigned long` on windows, but `int` on linux

4. The `available` variable wasn't initialised.

On windows, everything is the same size (32bits) and works as expected

On Linux; available is created with 64bits of uninitialised data FIONREAD writes 32bits The condition to print the log reads the full 64bits, and because of the unwritten upper 32bits of available, ends up (sometimes) passing The log message only reads 32bits, and prints Got a lot of data: 0 (or however much actually is available).

These small differences between platforms are annoying to deal with.

I've opted to zero initialise available, which should fix the issue, the variable is only used for logging, and you've confirmed the game works fine, so the only issue was the incorrect log spam.

Can you test the latest build on this pr to confirm it works

Works like a charm, would need to test more but no longer spamming :D

new pr:

Emulog:
emulog.zip

[F0bes]

Works fine from my testing. It is a lot faster now :^)