unsolicited multiline result

unsolicited multiline result

[Petteri Tikander]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]


This patch is for handling multiline unsolicited result-codes.
So state-machine used for handling result-bytes (gsmv1_feed) is set to the multiline-response
state. Otherwise next lines from the result-buffer are not handled correctly,
and response-handling will get stuck.

In the other hand, this correction keeps result-handling still unchanged.
So single line is notified to the upper level (atoms) at a time, not all lines of the result.
For instance: network-emergency numbers cannot be collect to the one single notification yet.
-- See us at Mobile World Congress, 14-17 February 2011, in Barcelona, Spain. Visit the Ixonos booth Hall 1, # 1E19.

[RFC PATCH] gatchat: support for unsolicited multiline result

[Petteri Tikander]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

---
 gatchat/gatchat.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/gatchat/gatchat.c b/gatchat/gatchat.c
index 96da657..200294c 100644
--- a/gatchat/gatchat.c
+++ b/gatchat/gatchat.c
@@ -418,6 +418,10 @@ static gboolean at_chat_match_notify(struct at_chat *chat, char *line)

        chat->in_notify = FALSE;

+       if (chat->syntax->set_hint)
+               chat->syntax->set_hint(chat->syntax,
+                                       G_AT_SYNTAX_EXPECT_MULTILINE);
+
        if (ret) {
                g_slist_free(result.lines);
                g_free(line);
--
1.7.0.4

-- See us at Mobile World Congress, 14-17 February 2011, in Barcelona, Spain. Visit the Ixonos booth Hall 1, # 1E19.

Re: unsolicited multiline result

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

Hi Petteri,

On 12/30/2010 10:55 AM, Petteri Tikander wrote:
> 
> This patch is for handling multiline unsolicited result-codes.
> So state-machine used for handling result-bytes (gsmv1_feed) is set to the multiline-response
> state. Otherwise next lines from the result-buffer are not handled correctly,
> and response-handling will get stuck.

I've never heard of multiline-unsolicited result codes.  Unsolicited
responses are always prefixed and suffixed by a crlf.  Are you trying to
combine the +CEN query and +CEN unsolicited responses into a single
parser by any chance?

> 
> In the other hand, this correction keeps result-handling still unchanged.
> So single line is notified to the upper level (atoms) at a time, not all lines of the result.
> For instance: network-emergency numbers cannot be collect to the one single notification yet.

Regards,
-Denis

Re: unsolicited multiline result

[Tikander Petteri]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

Hi Denis,

Actually I meant with multiline unsolicited results the same thing, as
you mentioned below:

+prefix: result data 1 <CRLF>
+prefix: result data 2 <CRLF>
...

And my problem originally was, that although the result-handler handled
the first line correctly, the next lines where missed.
So when looking state-machine gsmv1_feed() in gatsyntax.c:

when handling first byte of the second-line, state machine is in the
idle-state, but it thinks that first byte is echo-character, so it
switches to the echo-state, where it receives all other bytes of the
second line. Although in this state byte-counter works, state-machine
doesn't give in this state any valid result (G_AT_SYNTAX_RESULT_LINE
etc) to the calling function.

If I tested with two enters/line, different lines where recognized
correctly:
+prefix: result data 1 <CRLF><CRLF>
+prefix: result data 2 <CRLF><CRLF>

But then it's not according to TS.27007 (see +CEN, as well as +CCWA).

Thanks:)

Br, Petteri

On Thu, 2010-12-30 at 11:03 -0600, Denis Kenzior wrote:
> Hi Petteri,
> 
> On 12/30/2010 10:55 AM, Petteri Tikander wrote:
> > 
> > This patch is for handling multiline unsolicited result-codes.
> > So state-machine used for handling result-bytes (gsmv1_feed) is set to the multiline-response
> > state. Otherwise next lines from the result-buffer are not handled correctly,
> > and response-handling will get stuck.
> 
> I've never heard of multiline-unsolicited result codes.  Unsolicited
> responses are always prefixed and suffixed by a crlf.  Are you trying to
> combine the +CEN query and +CEN unsolicited responses into a single
> parser by any chance?
> 
> > 
> > In the other hand, this correction keeps result-handling still unchanged.
> > So single line is notified to the upper level (atoms) at a time, not all lines of the result.
> > For instance: network-emergency numbers cannot be collect to the one single notification yet.
> 
> Regards,
> -Denis
> 

Re: unsolicited multiline result

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

Hi Petteri,

Remember, no top-posting on this list ;)

On 12/30/2010 11:52 AM, Tikander Petteri wrote:
> Hi Denis,
> 
> Actually I meant with multiline unsolicited results the same thing, as
> you mentioned below:
> 
> +prefix: result data 1 <CRLF>
> +prefix: result data 2 <CRLF>
> ...
> 

I know what you mean, however last I checked there's no such thing as
multi-line unsolicited results.  Are you trying to invent something new
here?  Or is there a modem that might be implementing this already?

> And my problem originally was, that although the result-handler handled
> the first line correctly, the next lines where missed.
> So when looking state-machine gsmv1_feed() in gatsyntax.c:

Of course, because unsolicited results are assumed to be prefixed and
suffixed by a CRLF.  When you do something like:

<cr><lf>+CUNSOLICITED<cr><lf>+CUNSOLICITED<cr><lf> the parser gets
understandably confused.

However, I'm now starting to question how the spec writers ever intended
the implementation of unsolicited +CEN reporting to work on the
application side.  Not to mention other similar ones like +CPOSR.  When
the string / update is broken up over multiple unsolicited result codes
the application has no idea when the update has finished.

What is particularly challenging in the +CEN case is the fact that it
uses two different prefixes for such unsolicited reporting.
This makes it impossible to reliably update the emergency call list,
obtain CPOSR information, etc.

Since these features are relatively recent, maybe people who are
implementing these features in real modem firmware can chime in here.

Regards,
-Denis

Re: unsolicited multiline result

[Tikander Petteri]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

Hi Denis,

On Thu, 2010-12-30 at 12:51 -0600, Denis Kenzior wrote:

> I know what you mean, however last I checked there's no such thing as
> multi-line unsolicited results.  Are you trying to invent something new
> here?  Or is there a modem that might be implementing this already?
> 

Yep. There isn't mentioning about this kind of term as multi-line
unsolicited result-code. I just called those result-codes separated by
CR/LFs to multiline results (but naturally meaning multiply result
codes), so I had no intention to invent something new. Sorry for that,
it was probably confusing.

> However, I'm now starting to question how the spec writers ever intended
> the implementation of unsolicited +CEN reporting to work on the
> application side.  Not to mention other similar ones like +CPOSR.  

Thanks.

> When
> the string / update is broken up over multiple unsolicited result codes
> the application has no idea when the update has finished.
> 

That's true. There is no terminator ('OK' etc) in the end of the
unsolicited response for insuring that all the data has been received. 

> What is particularly challenging in the +CEN case is the fact that it
> uses two different prefixes for such unsolicited reporting.
> This makes it impossible to reliably update the emergency call list,
> obtain CPOSR information, etc.
> 

I was provisionally thinking to handle single result-codes one by one,
so notify single ECC-value to the atom. But it's not a nice solution,
because the whole ECC-list (if more than one emergency numbers are
received) is not send to the atom at the same time (not an nice solution
for instance for +CPOSR either, I believe). Well, the result code with
the another prefix (+CEN1) then will also be sent separately, which as
such isn't a problem. But probably two separated notify-functions for
'+CEN1' and '+CEN2' should be implemented.

Br, 
Petteri

Re: unsolicited multiline result

[Tikander Petteri]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

Hi Denis,

On Fri, 2010-12-31 at 19:07 +0200, Tikander Petteri wrote:

> > However, I'm now starting to question how the spec writers ever intended
> > the implementation of unsolicited +CEN reporting to work on the
> > application side.  Not to mention other similar ones like +CPOSR.  
> 
> Thanks.
> 

Have you got some explanation from the standard writers, what was the
idea for these multiple unsolicited codes to be encoded in the way,
TS.27007 says?

> > When
> > the string / update is broken up over multiple unsolicited result codes
> > the application has no idea when the update has finished.
> > 
> 
> That's true. There is no terminator ('OK' etc) in the end of the
> unsolicited response for insuring that all the data has been received. 
> 

One solution (nasty one) popped in my mind, if no indication of the last
result-code is received: usage of timer. So, after receiving some bytes
of the unsolicited message, possible remaining bytes could be monitored
by starting some timer for a while. If after timeout I/O-buffer is
empty, then hopefully the result is ready. But naturally this makes the
result-handling a little bit lazy, because the result is not sent to the
upper level immediately...

> > What is particularly challenging in the +CEN case is the fact that it
> > uses two different prefixes for such unsolicited reporting.
> > This makes it impossible to reliably update the emergency call list,
> > obtain CPOSR information, etc.
> > 
> 

I noticed in the oFono-mailing list some earlier discussion of the plans
for taking care of Location service API (as well as TODO-task marked to
be done). Is it still a valid case, so is it planned to be implemented?

Thanks!

Br, Petteri

Re: unsolicited multiline result

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

Hi Petteri,

On 01/14/2011 12:33 PM, Tikander Petteri wrote:
> Hi Denis,
> 
> On Fri, 2010-12-31 at 19:07 +0200, Tikander Petteri wrote:
> 
>>> However, I'm now starting to question how the spec writers ever intended
>>> the implementation of unsolicited +CEN reporting to work on the
>>> application side.  Not to mention other similar ones like +CPOSR.  
>>
>> Thanks.
>>
> 
> Have you got some explanation from the standard writers, what was the
> idea for these multiple unsolicited codes to be encoded in the way,
> TS.27007 says?

Not yet.

> 
>>> When
>>> the string / update is broken up over multiple unsolicited result codes
>>> the application has no idea when the update has finished.
>>>
>>
>> That's true. There is no terminator ('OK' etc) in the end of the
>> unsolicited response for insuring that all the data has been received. 
>>
> 
> One solution (nasty one) popped in my mind, if no indication of the last
> result-code is received: usage of timer. So, after receiving some bytes
> of the unsolicited message, possible remaining bytes could be monitored
> by starting some timer for a while. If after timeout I/O-buffer is
> empty, then hopefully the result is ready. But naturally this makes the
> result-handling a little bit lazy, because the result is not sent to the
> upper level immediately...
> 

The timer is the only solution I have thought of as well.  I do not see
any other way.  However, this solution is not really guaranteed to
always work as expected.  e.g. due to OS load conditions, other timing
quirks, etc.

So I'd rather not use it unless there's absolutely no other alternative.

>>> What is particularly challenging in the +CEN case is the fact that it
>>> uses two different prefixes for such unsolicited reporting.
>>> This makes it impossible to reliably update the emergency call list,
>>> obtain CPOSR information, etc.
>>>
>>
> 
> I noticed in the oFono-mailing list some earlier discussion of the plans
> for taking care of Location service API (as well as TODO-task marked to
> be done). Is it still a valid case, so is it planned to be implemented?
> 

I believe so, perhaps one of the STE guys can comment more.

Regards,
-Denis