для tcp в принципе ситуация resubmit не является какой-то ненормальной, потому как tcp суть протокол "гарантированной доставки", когда вне зависимости от процента потерь по пути (а на разных участках пути могут быть разные каналы связи с разным качеством и etc) данные либо доставляются в том порядке в котором они отправлены, либо не доставляются вообще.
грубо говоря, на уровне самого tcp ожидаемый процент потерь - 0%. Все что больше нуля - не правильно. на уровне сетевом (Ethernet) потери допустимы, на уровне tcp - из не может быть.
Теперь сама суть - каждое получение данных приемник подтверждает отправителю (http://ru.wikipedia.org/wiki/TCP).
то есть:
1) отправитель отсылает пакеты с номерами 1, 2, 3, 4, 5 (и в буфере отправки у него еще пакеты 6, 7, 8, 9)
таким образом, в буфере отправки пакеты имеют следующий статус:
1, 2, 3, 4, 5 - отправлен, не подтвержден
6, 7, 8, 9 - не отправлен
2) приемник получает пакеты с номерами 1, 2, 3, 5 - (потерялся пакет номер 4 - и это не важно где)
приемник отправляет назад сообщение "принял пакеты по номер 3 включительно"
3) передатчик получает сообщение "принято, максимальный номер принятого пакета - 3", удаляет из буфера пакеты 1-3, отправляет следующие 5 пакетов: 4, 5, 6, 7, 8
таким образом буфер на отправку выглядит как:
4, 5, 6, 7, 8 - переданы, нет подтверждения
9 - не передан
ну и дальше по этому же алгоритму пока все данные не будут переданы
что и как делает приемник с пакетом номер 5 при отсутствующем 4-ом вопрос конкретной реализации приемника, в рамках tcp должны быть повторно посланы все пакеты, получение которых не было подтверждено. ситуации, когда отправлено было 1, 2, 3 а пришло 1, 3, 2 - тоже реализуются на стороне приемника через организацию буфера приема, таймауты и разные алгоритмы, основная цель которых минимизировать resubmit пакетов если в пути пакеты перемешались и гарантировать приемлемую скорость получения данных с таймаутами "ожидания" при обработке "перемешанных пакетов" в последовательности приема.
что это означает:
1) возможно буфер отправки стоит увеличить - 8 пакетов это очень скромный буфер для на скорости отправки данных в восемь мегабит - это грубо буфер всего на ~ 12-15 миллисекунд. в качестве допинфы можешь почитать
http://www.securitylab.ru/analytics/243414.php - тут для домохозяет и эникеев пытаются рассказать что есть буфер и каков его размер должен быть. ну и вариантов есть несколько:
А) - увеличивать буфер у себя - возможно самый правильный вариант, хотя нужно оценивать гемморность добавления лишней памяти под этот буфер в твою эмбедовку
Б) - тюнить tcp-стек на клиенте - результат не гарантирован, возможность для этого есть только тогда, когда и клиента на уровне железяки ты тоже разрабатываешь.
В) - обучить алгоритмы, которые обрабатывают посылаемый тобой data flow в 8 мегабит (на клиенте имеется ввиду) к возможному протериванию части пакетов, возможно здесь имеет смысл использовать udp вместо tcp - но тогда "выстраивание" "цепочки данных" из udp пакетов целиком и полностью переносится на клиента.
где практикуют такое - ну это классика - voip / потоковое вещание, там в случае "провала" на каком-то этапе декодер тупо ждет следующий "ключевой кадр" и реинициализирует обработку данных с этого ключевого кадра.
что именно проще сделать - ну смотреть нужно, а вообще буфер отправки в 12 Кb для потока в 8 MB/s маловат будет...
)