Sleep() - плохой дизайн, но, похоже, это мой единственный вариант

Я пишу класс IO для загрузки/выгрузки файлов на контроллер по последовательному интерфейсу RS-232. К сожалению, я не могу отправить весь файл сразу, мне приходится разбивать его на пакеты и отправлять понемногу за раз. Вот основной подход...

ifstream file ("path/to/file.ext", ios::in | ios::binary);

while( !file.eof() )
{
    //... zero buffer, and add packet header (8 bytes)
    size_t nResult = file.read( &buffer[8], 129 );
    Serial.Write( buffer, nResult+8 );
    //... see if controller wrote anything to the serial port and process it's command
    Sleep( 600 );
}

Я знаю, что использование Sleep() не является хорошей практикой проектирования, но если я удалю оператор Sleep() или даже сокращу время сна цикла, контроллер выдаст ошибку о том, что его буфер переполнен, и передача завершится неудачей. Есть ли лучший способ сделать это?

Прежде чем вы это скажете, нет, я не могу послать сообщение контроллеру, чтобы определить, готов ли он к приему следующего пакета. У него нет такой функциональности.

Edit: Я забыл упомянуть, что интервал, с которым мне приходится спать, в некоторой степени "слепой". Спецификация протокола, предоставленная производителем, не содержит никаких подробностей о длительности интервала между пакетами. Поэтому мне пришлось определять это значение методом проб и ошибок. Я боюсь, что это может работать не на каждом ПК и, более того, может работать не на каждом контроллере.

Эта разработка ведется для Windows XP/Vista/7.

Edit #2: Кроме того, количество данных в пакете на самом деле тоже является методом проб и ошибок. Спецификация протокола допускает пакеты размером 65 535 байт (включая заголовок). Но если вы отправляете более 129 байт за раз, вы начинаете сталкиваться с проблемами, когда иногда это работает, а иногда нет. Также, похоже, существует зависимость между временем, которое вы должны спать, и количеством байт, которые вы можете отправить. Если я уменьшу размер пакета до 20 байт на пакет, я смогу уменьшить время сна до 400 миллисекунд. Я полагаю, что причина этих проблем кроется во времени, которое требуется контроллеру для перемещения данных из буфера в файл.