Операция над сокетом не может быть выполнена, потому что системе не хватило буферного пространства или потому что очередь была заполнена

У меня есть машина с несколькими приложениями, которые постоянно выполняют UNC-доступ (\\server-ip\share) так:

std::ifstream src(fileName, std::ios::binary);
std::ofstream dst(newFileName, std::ios::binary);
CopyFromRemote(ifstream &src, ofstream &dst);
dst.flush();
dst.close();
src.close();

void CopyFromRemote(ifstream src, ofstream dst)
{
char buffer[8192]; // read 8KB each chunk
while (src.read(buffer, sizeof(buffer)))
{
dst.write(buffer, sizeof(buffer));
// Here there is code that checks that some timer !> max read time so as
// to not be stuck if there is network issue with this src.
}
if (src.eof() && src.gcount() > 0)
{
dst.write(buffer, src.gcount()); // few bytes left
}
}

Как видно, сеть сильно напрягается, обходя ее для каждых 8 КБ (файлы имеют размер несколько МБ). Преимуществом здесь является возможность прервать копирование файла в случае, если это займет слишком много времени из конкретного источника.

Проблема, с которой я сталкиваюсь, заключается в том, что через несколько дней все UNC становятся недоступными с этой машины с ошибкой выше. Я не уверен, что источник проблемы, но это спорадический & трудно прибить Когда возникает проблема, 1-ая строка терпит неудачу (std :: ifstream src …). телнет также перестает работать.

Также: при уничтожении приложений UNC снова доступен. При перезапуске процессов UNC снова сразу становится недоступным. Перезагрузка машины решает проблему в течение нескольких дней.

Первоначально я думал, что это было Истощение порта но netstat не показывает слишком много подключений или зависших подключений, а на вкладке производительности диспетчера задач не отображаются ненормальные цифры. TcpQry показывает нормальные номера сопоставления TCP / UDP.

Также: захват пакета показывает, что при возникновении проблемы нет запроса (запрос не достигает сети). Просмотрщик событий ничего не раскрывает. Сделал следующие изменения реестра, хотя это, вероятно, только задержало бы проблему, но не устранило ее, но в любом случае это не помогло:

Найти autodisconnect значение в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters, Если его там нет, создайте новый REG_DWORD называется autodisconnect, Измените значение как шестнадцатеричное и установите его ffffffff,

найти KeepConn в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters, Если его не существует, создайте его как REG_DWORD значение и присвойте ему значение 65534.

найти HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и создать новый DWORD значение по имени MaxUserPort, Установите значение 65534.