а вы попробуйте%)...

пакеты приходить уходить чаще чем тикает быстрый таймер не будут, по определению работы стэка%) Я запускал на 1 мСек, но иногда случался спонтанный ретрансмит пакета, почему не выяснил, данные не терялись, стэк отрабатывал, но просос случался...

У меня сейчас почему то retransmitt с браузера происходит, иногда. И когда пакет приходит от платы reasambled pdu в чем дело пока не понял.

Никак не пойму в чем дело иногда не происходит повторных запросов

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

заметьте - если прийдёт другой ответ от клиента следом, то будет другое состояние конечного автомата, таймер уже будет не нужен,
и будет интерес к другому уже интервалу...

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


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

погодите, по быстрому таймеру дергается функция обработки стэка. Если эта функция не весит в нитке операционки, ее никто не дернет, а без этого стэк вообще ничего не отдаст не пошлет. Или вы про какие то другие таймеры?