с++ не знаю но думаю тут не от скорости инета зависит, а от размера оперативки.

sendfile

Что-то мне подсказывает, что это зависит от MTU.

А задержку лучше не фиксировать, а ждать от получателя подтверждения получения перед посылкой следующего блока. Тогда алгоритм будет сам подстраиваться под загруженность сети.

++ (если не нужно озабачиваться разрывами соединения)

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

Разбивать не надо. тсп сам разобьёт как надо.

Сделай ммап своему файлу и подсовывай send указатель с офсетом, который будешь сдвигать постоянно.

если надо только linux, используй sendfile, как указали выше.

Охренеть... В жопу С++! Они для этой задачи совсем не нужны. Используй например, libev. Когда сокет готов к записи пытаешся записать в него данные пока он не вернет размер меньше, чем ты пытаешся передать. После этого ждешь, пока он снова будет готов к записи. итд

MTU тут непричем. Абсолютно

От размера оперативки тоже ничего не зависит

В жопу С++! Они для этой задачи совсем не нужны. Используй например, libev

Человек лабу делает.

Тогда можно обойтись select в цикле. Ну или блокирующим режимом.

libcurl

Какой должен быть максимально возможный размер пересылаемых за раз данных?

Первое, лимит данных хранимых кернелом ограничен (это касательно MAX_FILE_SIZE). Во-вторых, если с сетью все нормально, пиши по 32-64кб. Обычно делают меньше от 512б до 8кб. С учетом буффера на чтение, оптимально брать 4к.

И решать лучше через mmap. Разницы как сдвигать офсет (по сравнению с read) - нет. Просто допишешь пару функций.

Да чего уж мелочится, давайте полностью TCP реализауем да и все тут.

Здравый смысл подсказывает, что нельзя сделать вот так

А почему нет? Здравый смысл подсказывает, что ограничений тут быть не должно.

Ты что, наркоман? Не твоя забота заниматься расчётами таймингов. Просто читай из файла куски и пиши их в блокирующий сокет. На счёт размера блоков, сотни кб и до половины среднего размера tcp буфера.

Обычно делают меньше от 512б до 8кб. С учетом буффера на чтение, оптимально брать 4к.

не делают так, 4к слишком мало

Пересылай одним куском, ядро само раздолбит на куски в зависимости от размера TCP window.

Странно, когда я увидел твою аватарку, не читая еще, что ты написал, решил, что будет простыня на хаскеле, которая умеет пересылать файлы, считать факториал и еще какую-то муть)

могу sendfile на haskell, но там 1 импорт и 1 вызов будет.

наверное, надо глянуть на досуге как это делает midnight commander

но разбить файлик на мелкие части, и пересылать понемногу...

... это если никуда не спешить.

int left = file_size;
int offset = 0;
while (0 < left) {
    int sent = send(fd, start + offset, left, 0);
    if (-1 != sent) {
        left -= sent;
        offset += sent;
    } else {
        // ...
    }
}

Операционная система сама разберётся как передать его побыстрее.

можно не смотреть, а сразу в поиск по лору

Копирование файлов

Асинхронность головного мозга детектед.

Можно, конечно, и более трудозатратные способы предложить.

Просто есть БОЛЬШОЙ опыт передачи и получения файлов по сети. Синхронный режим просто не рассматривается как тупиковый путь.

видимо, слишком БОЛЬШОЙ...

...чтобы решить простую практическую задачу.

Чем ТС хочет заниматься пока передача невозможна? И какого тогда передёргивать ядро? Возможно, на этом же хосте крутятся и другие программы, которые не прочь поработать.