WIP 5.3 - periodic http GET

I have been looking at HTTP GETs with WIP 5.1 at the end of 2008. Finally resulting in forcing both channels to always close and rebuild from scratch again for the next request, even though the manual states the HTTP session could be reused, see also
forum.sierrawireless.com/viewtop … 109&t=4567

Awneil, did this issue ever get a tracking number / any feedback?

This worked most of the time, and always on a desk/debug environment, but on some networks, it seemed as if WIP (error) events are simply not received. This occured only after several hours / days of normal operations. Never able to reproduce this intentionally, nor find a suitable way to recover from such a situation. Similiar problems are reported here forum.sierrawireless.com/viewtop … 535#p18533.

Since there are now several new WIP version, I had a look at WIP 5.30 to check if things got a bit better by now. The tested modem has an ethernet IESM card, so I can see what it is actually doing. Versions are:

Fastrack Supreme
Firmware: R7.43.0
Application: 6.32
Wip: 5.30

Interestingly enough the WIP HTTP client still seems to behave at least to say strange or I am completely missing something. The intention is quit simple, request a url (GET) on a regular interval in the minutes range. Below are (some) things I tried,

As per http_get example:

When opening a session the initial GET by HTTP/1.1 always goes fine, wip_close() is called on WIP_CEV_PEER_CLOSE for the data channel. In the meantime the remote server closes the connection since there is no activity (The KeepAliveTimeout of Apache is 15 seconds by default.); it sends a packet with FIN set. The modem ACKs the reception of the FIN.

The next request is scheduled say a minute later to the same url using the same HTTP session. WIP will then reuse the by now closed socket!! Resulting in a tcp packet with RST flag set from the remote side. The data channel receives therefore an error:

WIPEV WIP_CEV_ERROR @ TCPCLIENT 0x180c8cac (errno = WIP_CERR_ABORTED/-1000)

The next request succeeds again. So every other request results in an error if the remote side closes the connection in the meantime… There seems to be a bug in WIP 5.3 not handling the socket closure correctly. There should either be a peer close event on the session channel or subsequent requests should first check if the socket is still open, and if closed, open a new tcp socket instead.

So since the keep-alive does not work, I tried the reverse. Not keeping the TCP socket open but closing it directly; Added the header Connection: close and closing both channels in WIP_CEV_PEER_CLOSE on the data channel. This at least works without error events. Looking at the actual data sent, the connection is directly closed by the server (FIN) as requested. The modem send an ACK as response, so actually confirmes that it saw the frames. So this is completely fine so far. However wip_close insists on sending a RST to the already (confirmed) closed socket…!! No matter what I tried, wip_shutdown, defering wip_close of the session till the finalizer of the data channel is called etc, the wip_close always seems to want to send a RST as if the socket is still open. (the tcp data seems fine by not calling wip_close, but then the modem runs out of sockets ).

In short, it seems as if remote socket closing is not handled correctly, at least not for the HTTP client. Explicitly closing the connection seems to be the best thing to do, despite an additional RST being send. (which should not be there afaik, but is fine as long as WIP did not reuse the same port again).

Don’t know about the behaviour of 5.3 in the long run, but this seems not all too promising. Can anybody confirm above? Does anybody have experience with a reliable way to periodic log by HTTP, also for long periods of time with WIP 5. If so, which version of WIP is then used?

'fraid not. :cry: