1. General Setup of System
Well, there was that trouble connecting to the webserver mentioned in the previous post, which was more my fault at forgetting than anything. In addition, there's always the process of setting up new environments in Linux.
Notable obstacle was getting the python setup in the webserver to execute scripts properly in the beginning because of missing modules (the Raspberry had python pre-installed with the Linux distribution I installed it with).
More of the time obstacle than anything, and time (and some google searching for commands) solved this.
Solution: Time and Google
2. Session Management
Once I got a basic Websocket-compatible server running in the webserver with the help of Tornado (got some help from http://lowpowerlab.com/blog/2013/01/17/raspberrypi-websockets-with-python-tornado/. The site was for a Raspberry Pi, but I actually used it for an implementation for the webserver), I noticed that I was unable to send messages cross-session; each Websocket message originating from one session had no knowledge of other sessions currently running. This was a problem because it was the request message from the client that was needed for the server to relay the message to the target (Raspberry Pi), but the request message would not know where to send to. This was solved by... globals. I'm never a fan of global variables, but my zero-knowledge of Python did not help me find a better solution. Created a list that holds all the current active sessions and a target value that contains the session of the target device. This was done by assigning all the sessions a UIUD id upon creation.
I'll probably need a smarter solution, but this will do for now.
Solution: Global.. list and value that contain session information.
3. Wireless Network Adapter Going to Sleep upon idle
Once the code was functioning, I noticed that the target's session was closing after a rather random length of time. Seeing that I was not able to SSH into the Raspberry Pi once this occurs (and the network adapter, which has a blue status light, was not blinking or turning on), I concluded that the network adapter was shutting itself down after a period of idleness. I tried to find linux settings-based solutions, but nothing worked.
Because the straightfoward root of the problem was that the network was idle, I decided to make it not stay idle for too long. I made the target session to send a ping message to the central server every couple of minutes, and the sleeping stopped.
Solution: Have target device session ping messages to the central server to keep the session active.
4. ISP Downtime
Even after the above solution, it appeared to me that the session was still disconnecting, this time in a less pattern-based manner. After running well for a day or two, the target session would just disconnect. I had logging enabled by now, and it showed a "timeout" error message. This usually happened around the time I was at work, but one day I experienced first-hand what was happening--the ISP at home would have service downtime, varying in length, every couple of days/weeks. However, even a short downtime would close the target device's session with the server. The target needed something to restart itself.
The current solution I implemented sounds okay (of course, without a second opinion so potential for flaw is surely there), but I haven't had the chance to test it out yet--the session connection will run in a new thread, and once an error handler is triggered, the logic will try to start a new session connection thread after a short length of time (while the other will... close once the error handling logic is completed?). If the internet service is still down, hopefully the new thread connection will throw once again another error for which the handler will call a new connection thread.
Service hasn't been down since this was implemented.
Solution (Pending): Make the target's connection to the server a thread in the main script so that it can be created anew without having to restart the whole script.
I'll definitely find better solutions as I continue to work on this. Will try to update when I do.
Well, there was that trouble connecting to the webserver mentioned in the previous post, which was more my fault at forgetting than anything. In addition, there's always the process of setting up new environments in Linux.
Notable obstacle was getting the python setup in the webserver to execute scripts properly in the beginning because of missing modules (the Raspberry had python pre-installed with the Linux distribution I installed it with).
More of the time obstacle than anything, and time (and some google searching for commands) solved this.
Solution: Time and Google
2. Session Management
Once I got a basic Websocket-compatible server running in the webserver with the help of Tornado (got some help from http://lowpowerlab.com/blog/2013/01/17/raspberrypi-websockets-with-python-tornado/. The site was for a Raspberry Pi, but I actually used it for an implementation for the webserver), I noticed that I was unable to send messages cross-session; each Websocket message originating from one session had no knowledge of other sessions currently running. This was a problem because it was the request message from the client that was needed for the server to relay the message to the target (Raspberry Pi), but the request message would not know where to send to. This was solved by... globals. I'm never a fan of global variables, but my zero-knowledge of Python did not help me find a better solution. Created a list that holds all the current active sessions and a target value that contains the session of the target device. This was done by assigning all the sessions a UIUD id upon creation.
I'll probably need a smarter solution, but this will do for now.
Solution: Global.. list and value that contain session information.
3. Wireless Network Adapter Going to Sleep upon idle
Once the code was functioning, I noticed that the target's session was closing after a rather random length of time. Seeing that I was not able to SSH into the Raspberry Pi once this occurs (and the network adapter, which has a blue status light, was not blinking or turning on), I concluded that the network adapter was shutting itself down after a period of idleness. I tried to find linux settings-based solutions, but nothing worked.
Because the straightfoward root of the problem was that the network was idle, I decided to make it not stay idle for too long. I made the target session to send a ping message to the central server every couple of minutes, and the sleeping stopped.
Solution: Have target device session ping messages to the central server to keep the session active.
4. ISP Downtime
Even after the above solution, it appeared to me that the session was still disconnecting, this time in a less pattern-based manner. After running well for a day or two, the target session would just disconnect. I had logging enabled by now, and it showed a "timeout" error message. This usually happened around the time I was at work, but one day I experienced first-hand what was happening--the ISP at home would have service downtime, varying in length, every couple of days/weeks. However, even a short downtime would close the target device's session with the server. The target needed something to restart itself.
The current solution I implemented sounds okay (of course, without a second opinion so potential for flaw is surely there), but I haven't had the chance to test it out yet--the session connection will run in a new thread, and once an error handler is triggered, the logic will try to start a new session connection thread after a short length of time (while the other will... close once the error handling logic is completed?). If the internet service is still down, hopefully the new thread connection will throw once again another error for which the handler will call a new connection thread.
Service hasn't been down since this was implemented.
Solution (Pending): Make the target's connection to the server a thread in the main script so that it can be created anew without having to restart the whole script.
I'll definitely find better solutions as I continue to work on this. Will try to update when I do.
Comments
Post a Comment