Pronto sleep just means that the pronto stops the processor. In theory state would be maintained, but TCPIP gets very tricky depending on the other side. I always check a socket before connecting and I always run the sockets async and capture all errors. The pronto wakes up about once a minute in an attempt to keep a wifi connection alive. It then goes back to sleep if there was no user action for aboput 5 seconds (My understanding, not necessarily fact).

In all my TCPIP work:

1) All the code is at the activity level. In fact this is true for all my xcf work

2) There is a loop called the 'BasicLoop" that is at the activity level that is called from every page (actually the currently active page) every 100 milliseconds using the page timer.

3) All buttons and hard keys, with the exception of the Home key which has special hold down actions, just make an entry into a user queue signifying what button was pressed and passing any parameters like the buttons position is a list of buttons.

4) The basic loop acts as a finite state machine switching on a single state variable. The user queue is checked only if the current loop state is idle. TCPIP comms are timed as long as the loop state is busy and restarted when they time out . TCPIP, a guaranteed delivery protocol, can fail to guarantee delivery under certain instances of a wifi failure. Sleep wake up recognition takes place in the basic loop.

5) All TCPIP work is queue based. An entry is made in a comm queue and the comm queue is processed, guess where - in the Basic loop. The system allows new entries to be added to the queue at any time even while processing a queue entry. The comm Queue entry is always a list of items (a small queue)which consist of multiple TCPIP commands each one processed in order and allows for evaluation of processed results as replies are received. It is referred to as the current work list. An entry in the list is either something to send, something to evaluate, or a place to go. Processing of a reply may add more entries to the basic queue or the currently active queue block or may change the Basic loop state. That is the way I chunk long lists that require telling a server to advance through a list of items. The bottom of any queue list always contains a return point to be executed when the entire block is finished.

Hope that helps

The Finitestate machine has states like Idle, Busy, Done, Stop, Hold, Error. The normal cycle is Idle, Busy (processing a comm queue block), Done (finsihed processing a comm queue block), Idle

A TCPIP entry in a comm block might be an http GET.