Как обрабатывать сообщение 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 раз. И это не просто процедура инкремента, а попытка найти в буфере какую-то строку, соответсвующую определённому шаблону. Шаблоны как я понимаю должны быть приготовлены для всех вариантов ответа.
Если же всё таки начинать распознавание ответа по признаку количества принятых байт, или ещё какому-то признаку, то это не меняет концептуально подход. Просто меняется признак, по которому начинается обработка. А смысл тот же. Ждём признак, а получив - идём на распознование.

[Guest_@Ark_*]

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

Здесь, конечно, вопрос реализации... Кто и как выполняет процедуру приема... Если это делает Ваша программа (процедура), причем, асинхронно - по прерыванию на прием символа, то почему бы не совместить прием с распознованием? Где Вы увидели усложнение? Сам подход Вам не привычен? Это возможно...

[david_off]

Здесь, конечно, вопрос реализации... Кто и как выполняет процедуру приема... Если это делает Ваша программа (процедура), причем, асинхронно - по прерыванию на прием символа, то почему бы не совместить прием с распознованием? Где Вы увидели усложнение? Сам подход Вам не привычен? Это возможно...

Наверно вы правы в том, что мы по разному понимаем реализацию распознования.
Я когда хочу что-то распознать, то начинаю сравнивать содержимое буфера с какой-то последовательностью байт (текстовые контстанты, соответсвующие разным вариантам ответа). Сравнение происходит в цикле до появления первого расхождения в байтах.
Так вот при моей реализации распознавания получается, что после приёма нового байта, приходится снова, с самого начала буфера, попытаться найти сходство с каким-то из возможных вариантов ответа.
А как вы распознаёте?