Сейчас посмотрю. Откуда же ей взяться если буду все бросать С помощью профи как на этом форуме все получиться.
В этом много того что мне не нужно , нужен простой по такому принципу поступил запрос отправили 200 и страницу. Так то все работает запрос приходит функции разбора запроса уже есть, проблема я что то не так или не втой последовательности делаю.
Сейчас так: как запускается callback_receive в нем разбираю запрос, и туже отправляю tcp_write. Смотрю что происходит ваиршарком запрос с пк уходит. В плату приходит, но после запроса должен быть ACK и 200 потом страница. но вместо этого ваиршарк показывает ethernet 2 вместо tcp или http. Может нужно еще что то делать в callback_send /pool/err сейчас они пустые?

Не выходит никак ничего )). В чем может быть дело, нужно отправить 10кб, пытаюсь отправить в цикле tcp_write() перед этим смотрю tcp_sndbuf(pcb); при первом проходе получаю размер 2500 этот пакет уходит а при втором проходе цикла tcp_sndbuf(pcb); возвращает 0 .

Все заработало причина была в этом флаге TCP_WRITE_FLAG_MORE.

Как ускорить процесс, сейчас в tcp_pool (foo,4) в функции foo отправляю ответ но это происходит 1 раз в 4 секунды если ответ разбит на несколько отправлений то страница может загружаться 10 секунд? Если снизить с4 до 1с то это тоже долго.

Если увеличить скорость быстрого и медленного таймера?

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

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

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

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

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

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

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


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

Сообщение отредактировал kolobok0 - Feb 12 2014, 12:27

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