Как обрабатывать сообщение 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

[Baser]

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

А я так и не пойму, как при таком алгоритме можно принимать не только сообщения модема, но еще и данные, которые сыпятся по GPRS-у (или по CSD). Я уже писал об этом тут рядом.

У меня основа алгоритма - кольцевой приемный буфер достаточного размера, чтобы разместить мах возможный пакет данных + несколько ответов модема, включая незапрашиваемые (unsolicited).
Признак получения данных - таймаут (дырка в данных) в ~50ms
После чего начинает работать обработчик по разбору всего, что пришло (причем в это время могут начинать валится новые данные, они попадут дальше в кольцевой буфер и будут обработаны позднее)

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

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

Еще добавлю, что работать с модемом без операционки я не рискую, уж больно большой гемор
Правда, я сам полноценную ОС не использую, а применяю ее зачаток, где кроме главного цикла и прерываний есть еще один поток, в котором выполняются модемные процедуры и можно применять "ожидания событий", во время которых крутится главный цикл (ну и прерывания ессно)

[FormatCft]

А я так и не пойму, как при таком алгоритме можно принимать не только сообщения модема, но еще и данные, которые сыпятся по GPRS-у (или по CSD). Я уже писал об этом тут рядом.

У меня основа алгоритма - кольцевой приемный буфер достаточного размера, чтобы разместить мах возможный пакет данных + несколько ответов модема, включая незапрашиваемые (unsolicited).
Признак получения данных - таймаут (дырка в данных) в ~50ms
После чего начинает работать обработчик по разбору всего, что пришло (причем в это время могут начинать валится новые данные, они попадут дальше в кольцевой буфер и будут обработаны позднее)

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

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

Еще добавлю, что работать с модемом без операционки я не рискую, уж больно большой гемор
Правда, я сам полноценную ОС не использую, а применяю ее зачаток, где кроме главного цикла и прерываний есть еще один поток, в котором выполняются модемные процедуры и можно применять "ожидания событий", во время которых крутится главный цикл (ну и прерывания ессно)

А почему бы еще плюсом очереди (queue) не использовать?

[Baser]

А почему бы еще плюсом очереди (queue) не использовать?

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