SSI implementation issues

[jarno2]

Posted on October 19, 2015 at 09:01

I think that there are some issues with the SSI implementation that I would like to point out. I hope that you could post this forward to the firmware developers of the module.

First, the SSI WIND event does not conform to the specified asynchronous indication format(UM1695, rev.5, page 4), which is

<cr><lf>+WIND:<number>:<descriptive string><cr><lf>

Instead the generated WIND event is

<cr><lf>+WIND:56:Insert message to client:<ID>

So in the other words the ending <cr><lf> are missing. This looks nice and fine for human operator on the console, but will require workaround the line parser which I would like to omit.

Second, if the response is not sent in time the device sends notification of this using just plain text “TIMEOUT OCCURRED!. It would be better if the initial indication was formatted correctly and the timeout indication would be another WIND indication. Once more this requires special handling which is not good.

Thirdly there is a possibility of probable race condition here. SPWF expects the host to send the response after sending the WIND indication. However at the same time the host might be starting some AT command or pushing data to the device. This might result in some wrong data being displayed on the SSI replacement. Consider following:

SPWF

Host

send: <cr><lf>+WIND:56:Insert message to client:<ID>

send: AT+S.SCFG=something,whatever

receive: AT+S.SCFG=something,whatever

receive: send: <cr><lf>+WIND:56:Insert message to client:<ID>

display:  AT+S.SCFG=something,whatever

send: Data for SSI

So, instead of expecting data directly, the SSI replacement should be operated via AT command, say AT+S.SSIR=<data for response>, this way it handling of SSI response data would be explicit.

To summarize I propose following changes:

1. Fix SSI event to conform to syntax: <cr><lf>+WIND:56:Insert message to client:<ID><cr><lf>
2. Add new event for missed SSI completions: : <cr><lf>+WIND:79:Missed SSI completion:<ID><cr><lf>
3. Make SSI responses explicit via at command: AT+S.SSIR=<data for response>

I believe that this would make use of SSI features much easier on the host, as need for special cases and workarounds would be eliminated.

Regards,

Jarno

[Gerardo GALLUCCI]

Posted on October 19, 2015 at 22:21

Hi Jarno,

first of all, thanks for your detailed analysis. We will take care of it. I want to share some evaluation. 1 - WIND:56 was updated since FW3.4 Old behaviour: ''+WIND:56:Insert message to client:%d'' New behaviour: ''+WIND:56:Insert message to client:%s'' or generic ''+WIND:56:Insert message to client'', depending on SSI format (with or without '':tag''). Basically, incremental ''%d'' turned to user-defined ''%s'' We need to update manuals. Thanks. In both cases, ending ''\r\n'' is missing. Its only a look&feel detail, which affects both input_demo (missing ''\r\n'') and output_demo (missing ''+WIND'' at all!). We cannot change this behaviour because of old customer's code. 2 - after WIND:56 notification, external host needs to provide a result within 2000ms. If not, that SSI is skipped (''TIMEOUT'' string), and CGI engine passes to next SSI in the HTML page. The reason the ''TIMEOUT'' string is not another WIND is related to point #1: ''\r\nWIND:TIMEOUT\r\n'' should be very fine in case of ''\r\nWIND:56\r\n''. Cannot change now. 3 - during WIND:56 event (ending with a \r or \r\n), module is not able to accept and parse AT commands. This means external host must be aware of this: do not provide AT commands during WIND:56 event. Thanks for your proposals. We will discuss about them for the future! Ciao jerry

[jarno2]

Posted on October 20, 2015 at 08:21

Hello,

Some additional feedback.1. Missing <cr><lf> is not just a look and feel issue. AT protocol is inherently line oriented, which paradigm is broken by violation of this format. This makes implementation of robust line detection -> line tokenization -> line state machine implementation more complicated.Currently I work around this by detecting the formatting violations in the line detection and passing ''correct'' data forward.3. Exactly my point, only that the host has no reliable way of knowing what the HTTP client is going to do. 🙂Regards,Jarno

[Steve Wood]

Posted on May 26, 2017 at 21:09

Why not add another SSI input tag with a different name like <!--inputLFCR-->   ?     This no newline thing is a real pain in the ass, and NOT just a look and feel issue.

[Steve Wood]

Posted on May 26, 2017 at 21:16

A related question:   Is it some how possible to insert CR LF as  characters in the WIND:56:Insert message to client:blahblah    tag?    This would accomplish the goal.

[Steve Wood]

Posted on May 26, 2017 at 21:17

If so,

What is the syntax?