Как обрабатывать сообщение REMOTE IP: Опции

[david_off]

В моей программе все сообщения обрабатываются по установке флага получения нового сообщения. Анализатор флага работает так: получив CRLF (начало) - начинает ожидать CRLF(конец). Как только получен конец - флаг устанавливается. Обработчик сообщений, получив флаг, смотрит в буфер и обрабатывает пришедшее сообщение. После обработки флаг сбрасывается.

Алгоритм работает шикарно. Единственный его нюанс - нельзя работать с командами типа CLCC, которые возращают несколько строк и строки начиная со втрой не имеют CRLF (начало). Данные ответы имеют вид: CRLF<line1>CRLF<line2>CRLF...<lineN>CRLF OK CRLF. Проблема решается путём отказа от таких комманд - они мне не нужны.

Так вот с сообщением <CRLF REMOTE IP:> тоже наблюдается лажа.
Есть вариант выхода из сложившейся ситуации следующий: после соединения модулей посылать текст, который всегда будет заканчиватся на CRLF. Тогда сообщение будет иметь вид
<CRLF REMOTE IP: текст CRLF> - такое корректно обработается.

Но вот найти решение корректной обработки, когда приходит RING или ещё какое-то неожиданное сообщение - не могу. По сему спрашиваю здесь. Как обрабатывать REMOTE IP на тот случай, если влазит кто-то?

Сообщение отредактировал david_off - Nov 7 2008, 11:20

[PIC_Embedder]

У меня получилось что-то среднее. Алгоритм такой. Ожидаю первый символ (любой). Потом ожидается символ LF и если в течении 3 Мс нет нового символа, то считаем это признаком конца сообщения. Скорость установил 9600. Всё работает.

[david_off]

У меня получилось что-то среднее. Алгоритм такой. Ожидаю первый символ (любой). Потом ожидается символ LF и если в течении 3 Мс нет нового символа, то считаем это признаком конца сообщения. Скорость установил 9600. Всё работает.

неплохой вариант, только я хочу уточнить. Если получен LF, а заним ещё что-то лезит, то это уже снимает проверку таймаута?
Если да, то тогда REMOTE IP, который не имеет вконце LF также не будет обработан как и в моём алгоритме.
Если нет, то тогда вообще зачем ждать LF - алгоритм становиться такой же как описан выше.

[_zag_]

неплохой вариант, только я хочу уточнить. Если получен LF, а заним ещё что-то лезит, то это уже снимает проверку таймаута?

я думаю не снимает проверку таймаута а обнуляет таймер.

[david_off]

Думал, думал и надумал...

По суте у меня выбор между двумя вариантами: моим и вариант с таймаутами.
У моего есть минус, что он не ловит сообщения, которые не заканчиваются на CRLF
У второго - не ловятся и не обрабатываются сообщения, которые были получены сразу же за сообщением, которое запустило таймер. Т.е. когда начало второго ответа успело начать приходить раньше таймаута.

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

Для тех кто делал тайм-ауты наверно будет понятней сказать так. Буду ждать тайм-аута, но по мере поступления данных, буду проверять а нет ли внутри потока уже готового для обработки сообщения.

Сообщение отредактировал david_off - Nov 7 2008, 16:32

[Guest_@Ark_*]

Думал, думал и надумал...

По суте у меня выбор между двумя вариантами: моим и вариант с таймаутами.
У моего есть минус, что он не ловит сообщения, которые не заканчиваются на CRLF
У второго - не ловятся и не обрабатываются сообщения, которые были получены сразу же за сообщением, которое запустило таймер. Т.е. когда начало второго ответа успело начать приходить раньше таймаута.

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

Для тех кто делал тайм-ауты наверно будет понятней сказать так. Буду ждать тайм-аута, но по мере поступления данных, буду проверять а нет ли внутри потока уже готового для обработки сообщения.

Предложу Вам такой вариант обработки:
Начало сообщения определяется по приему символа LF. Символ CR можно проигнорировать (чтобы не путать с эхом команд). После приема LF, сразу, в процессе приема, нужно начинать распознавать сообщение (как - это Вам уже известно). Как только распознавание закончено - можно считать законченной и обработку сообщения - выставлять флаг и, возможно, код сообщения. Только, конечно, не тот код, что выдает модем, а собственный, присвоенный Вами данному сообщению. Далее весь ввод игнорируется до получения начала нового сообщения. Примерно так.

[david_off]

Предложу Вам такой вариант обработки:
Начало сообщения определяется по приему символа LF. Символ CR можно проигнорировать (чтобы не путать с эхом команд). После приема LF, сразу, в процессе приема, нужно начинать распознавать сообщение (как - это Вам уже известно). Как только распознавание закончено - можно считать законченной и обработку сообщения - выставлять флаг и, возможно, код сообщения. Только, конечно, не тот код, что выдает модем, а собственный, присвоенный Вами данному сообщению. Далее весь ввод игнорируется до получения начала нового сообщения. Примерно так.

Вы предлагаете после получения КАЖДОГО байта (когда уже был LF) пытаться распознать что у нас лежит в буфере приёма?! Мне кажется это будет нерационально расходовать процессорное время.
Получается для распознования элементарного ответа IP INITIAL на команду CIPSTATUS прийдётся запустить процедуру распознования содержимого более 10 раз. И это не просто процедура инкремента, а попытка найти в буфере какую-то строку, соответсвующую определённому шаблону. Шаблоны как я понимаю должны быть приготовлены для всех вариантов ответа.
Если же всё таки начинать распознавание ответа по признаку количества принятых байт, или ещё какому-то признаку, то это не меняет концептуально подход. Просто меняется признак, по которому начинается обработка. А смысл тот же. Ждём признак, а получив - идём на распознование.