Socket additional send/receive window buffering

[codecat]

It would be nice to add additional send & receive window buffering for sockets, so that we can send very large amounts of data in 1 go and/or have more reliable sending & receiving on slower connections.

This can be accomplished by polling & updating buffers on send & receive, but also once every frame for any open socket. This would require bookkeeping on sockets per plugin as well, much like how hooks & memory allocations are handled.

As a temporary workaround for now (at least for sending) you may use IsReady() (previously CanWrite()) to see if it's possible to write into the buffer. Note that this doesn't necessarily mean all bytes will be written to the socket, and there is currently no way to see how many bytes are actually written.

[XertroV]

Map info does have an issue sometimes joining rooms that are created with a large initial map, and I've suspected it might be to do with connection speed or things. Might be an example of large packets being an issue (these can be over 1 MB). Maybe related to the socket buffers thing too.

[codecat]

Here's a failing test for a 1 MB send. On the server:

while true; nc -l 4444 | pv -L 50k | wc; end

On the client:

void Main()
{
    string buf;
    while (buf.Length < 1000 * 1000) {
        buf += "AAAAAAAAAA";
    }

    print("buf size = " + (buf.Length / 1000) + " KB");

    auto sock = Net::Socket();
    sock.Connect("127.0.0.1", 4444);
    while (!sock.IsReady()) {
        yield();
    }
    sock.WriteRaw(buf);
    sock.Close();

    print("done");
}

[codecat]

I am now uncertain whether the sending end or the receiving end is at fault, as send() returns the expected amount of bytes at all times when the test case fails 😢 I'll have to get back to this later. For future reference: I made a branch feature/socket-resource for this.

[XertroV]

Does it fail with new sockets or just old sockets?

if it fails with new sockets are we still going live with that before it's resolved?

[codecat]

Old sockets also have this problem.

[codecat]

Increasing SO_RCVBUF and SO_SNDBUF to 32 MiB instead of the default 64 KiB seems to have improved some things. I am unsure if this is going to bite us in the ass at some point, but for now it seems like this is a decent way to go.

I'll leave this issue open for a bit until this has been tested more thoroughly.