10 Replies Latest reply on Jul 25, 2010 6:37 PM by snorky

    URLMonitor - Bandwidth and Other Issues

    snorky Level 1

      I have a new AIR app about to launch and it needs to check for internet connection when it runs. I have read through all of the Adobe tutorials, Tour de Flex tuts, watched Adobe videos, etc. And it seems simple BUT I have some concerns that are not addressed anywhere that I have found.

       

      1) Every Adobe example seems to say that I should set up URLMonitor to run continuously. That is quite convenient for my app but seems terribly wasteful in bandwidth. If I only need to know about connectivity once an hour am I not wasting bandwidth by "hitting" the URL continuously over that hour? Also, am I not filling my server logs with useless "hits" during that same period?

       

      2) Related to the above, some of the Adobe examples show the use of www.Google.com. In one Adobe video Daniel Dura says, "We create a new URLRequest and in this case I'll just use Google.com because that's the easiest thing to use"! Is this not a MAJOR problem when my app gets extremely popular and thousands of users are hitting Google continuously? I guess I should know better than to use Google but I'm concerned about my own bandwidth and Adobe says its OK so...

       

      3) To reduce the bandwidth used I have considered setting URLRequest method as "HEAD" which seems to me to be the proper approach since I don't really need to resource I'm getting, I'm just checking to see if it is available. But Rick Winscot points out (http://www.quilix.com/node/26) that some servers like Amazon.com do not allow HEAD requests and fail with a 405 MethodNotAllowed.

       

      4) Another point Rick makes is that some servers do not return the error message and instead return 200 along with a healthy serving of spam!

       

       

      So, I guess I have concluded that a) it is VERY BAD to use anyone's server in the URLMonitor other than my own and b) I need to be extremely careful that I do not add significant "traffic" to my website and useless hits to my server logs.

       

      I have tentatively come up with the following plan,

       

      -set up a special page on my server that will only be requested by my AIR app; that way I can filter it out of my server logs

      -only use HEAD in the URLRequest; that way I can reduce bandwidth as much as possible

      -start the URLMonitor immediately before I need to check status and then stop it ASAP after status is confirmed; that way I eliminate unnecessary hits on my server

       

       

      I guess I have two questions...

       

      1) are my concerns valid or is the overall effect of using URLMonitor as advertised negligible?

       

      2) if its not negligible is my approach sound and complete?

       

       

      Thanks in advance for any thoughts, ideas, discussion, etc.!

        • 1. Re: URLMonitor - Bandwidth and Other Issues
          snorky Level 1

          one more thing to clarify...

           

          Apparently the default value for URLMonitor.pollInterval is 0 which means the monitor is essentially only monitoring your local network connectivity and NOT the remote resource. So anyone serious about using this to confirm a remote resource MUST set the value of URLMonitor.pollInterval to something higher than 0! All of my comments above about bandwidth assumed a setting higher than 0.

          • 2. Re: URLMonitor - Bandwidth and Other Issues
            snorky Level 1

            AIR Team - any thoughts on this? best practices?

            • 3. Re: URLMonitor - Bandwidth and Other Issues
              snorky Level 1

              really? no thoughts?

               

              "is this thing on?" <taps microphone>

              • 4. Re: URLMonitor - Bandwidth and Other Issues
                snorky Level 1

                It'd be nice if someone from the AIR team would drop in and say something helpful on this topic or even say it is a stooopid question that no one in their right mind should ever ask. Or maybe a simple "we don't know". Or something.

                • 5. Re: URLMonitor - Bandwidth and Other Issues
                  abeall Level 3

                  "I have a new AIR app about to launch and it needs to check for internet connection when it runs"

                   

                  URLMonitor  is for monitoring the availability of a specific service url, not  internet connectivity. You can listen directly for network availability  via the NativeApplication networkChange event:

                   

                  http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/desktop/NativeApplicat ion.html#event:networkChange

                   

                  Also, the URLMonitor class just polls a url, and you can set that interval to be an hour if you want, or even never (so it only checks once when you call start()):

                   

                  http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/air/net/ServiceMonitor.html# pollInterval

                  • 6. Re: URLMonitor - Bandwidth and Other Issues
                    snorky Level 1

                    networkChange event does NOT confirm internet connectivity. "A networkChange event does not necessarily mean that the host computer has gone online or offline"

                     

                    URLMonitor seems to be the obvious choice since internet connectivity is an obvious requirement to successfully access a resource on the internet. and of course I understand that the lack of connectivity to a specific online resource does not confirm there is no internet connection; maybe that resource is down.

                     

                    but, when you are doing an AIR app that needs to talk to a specific internet resource, URLMonitor on that resource seems to be the only viable solution for knowing whether it is accessible prior to trying to use it.

                     

                    so I guess I still have the same questions about how to create a reliable internet resource checker without causing a lot of wasted traffic. so far it seems the ideas I listed at the end of my orignal post are the best approach,

                     

                    -set up a special page on my server that will only be requested by my AIR app; that way I can filter it out of my server logs

                    -only use HEAD in the URLRequest; that way I can reduce bandwidth as much as possible

                    -start the URLMonitor immediately before I need to check status and then stop it ASAP after status is confirmed;that way I eliminate unnecessary hits on my server

                    • 7. Re: URLMonitor - Bandwidth and Other Issues
                      abeall Level 3

                      Right, but:

                       

                      "A networkChange event does not necessarily mean that the host computer has   gone online or offline; it may just be transitioning from one type of    connection to another."

                       

                      So if you have internet connection, you don't really need to check in a general sense except when the networkChange event fires.

                      start the URLMonitor immediately before I need to check status and then stop it ASAP after status is confirmed;that way I eliminate unnecessary hits on my server

                       

                      Well, this seems a bit redundent since this behavior is built in to URLMonitor -- start() will only check the url once, unless you tell it to keep checking via .pollInterval. If you tell it to keep checking you can set the interval to be a long period of time, but the point of this is to confirm the availability of that specific url, because the network status hasn't changed.

                       

                      Maybe this is what you're already doing, but I believe the "best" solution is to simply call urlMonitor.start() when you app loads, and call urlMonitor.start() inside the networkChange event.

                       

                      I agree that setting up a page on your server is a good idea. As far as wasting bandwidth, I guess that's up to you, but I wouldn't be worried about it...

                      • 8. Re: URLMonitor - Bandwidth and Other Issues
                        snorky Level 1

                        So if you have internet connection, you don't really need to check in a general sense except when the networkChange event fires.

                         

                        actually I do need to! I need to also confirm that the resource I am seeking is currently available. networkChange will never tell me that.

                         

                        I believe the "best" solution is to simply call urlMonitor.start() when you app loads, and call urlMonitor.start() inside the networkChange event

                         

                        the problem here is it assumes the internet resource I am seeking is available and that might not be the case. maybe a router failed further upstream that prevents connectivity. maybe the website I am trying to reach is down. etc. the only sure way I can see is to test the desired resource for availability before using it.

                         

                        As far as wasting bandwidth, I guess that's up to you, but I wouldn't be worried about it

                         

                        is there a point at which you would worry about it? would you set up an AIR app to make a server request once per second? would it begin to concern you if 1,000 people installed your app (1000 requests/second/24/7/365!)? what if the number rises to 10,000 or 1 million? at some point it seems to me that there will be some serious traffic that is being generated for no real reason other than to share status! so my strategy has been to only hit the server when I need something and then to do so very quickly and stop. I was hoping for some sort of "best practice" from Adobe or other experts but all I could find was "set urlMonitor to poll frequently" and " use Google to connect to"!

                        • 9. Re: URLMonitor - Bandwidth and Other Issues
                          abeall Level 3
                          actually I do need to! I need to also confirm that the resource I am seeking is currently available. networkChange will never tell me that.

                          ...

                          the problem here is it assumes the internet resource I am seeking is available and that might not be the case. maybe a router failed further upstream that prevents connectivity. maybe the website I am trying to reach is down. etc. the only sure way I can see is to test the desired resource for availability before using it.

                          Oh, then yes, for a specific resource you rely on URLMonitor.

                           

                          is there a point at which you would worry about it? would you set up an AIR app to make a server request once per second? would it begin to concern you if 1,000 people installed your app (1000 requests/second/24/7/365!)? what if the number rises to 10,000 or 1 million? at some point it seems to me that there will be some serious traffic that is being generated for no real reason other than to share status! so my strategy has been to only hit the server when I need something and then to do so very quickly and stop. I was hoping for some sort of "best practice" from Adobe or other experts but all I could find was "set urlMonitor to poll frequently" and " use Google to connect to"!

                           

                          If I had a million users for a webapp (with AIR frontend) I would have some killer servers to begin with, so I probably wouldn't be too worried, no. Setting up a special lightweight "ping" url is something I'd definitely do and have done. I don't know the exact nature of your web service but if you don't expect to need the service very often (you mention one hour intervals), you can just set the pollInterval pretty low, say a minute or 5 minutes. The thing is no matter what you do with URLMonitor it's still possible your URLRequest to the service will fail, so you have to be setup to handle that anyway. If you are hitting the service so infrequently at some point IMO it fails to be important to monitor the URL beforehand anyway, certainly not down to 1 second intervals.

                           

                          As for best practice, I don't know what tutorials you are referring to but I highly doubt using google as a ping back is best practice, it was probably just convenient to use in the tutorial because someone watching and following along might not have their own server to hit. For your app I would say it's pretty safe to say setting up your own server ping back page is best practice. Otherwise your best practice is the one you make that works the best for you.

                           

                          BTW I'm not on the Adobe AIR team or any authority by any means, I just saw your post and thought I could clarify something from what I know -- however I think I was a little confused on your original post and I'm not sure I've offered anything useful anyway.

                          • 10. Re: URLMonitor - Bandwidth and Other Issues
                            snorky Level 1

                            BTW I'm not on the Adobe AIR team or any authority by any means, I just saw your post and thought I could clarify something from what I know -- however I think I was a little confused on your original post and I'm not sure I've offered anything useful anyway.

                             

                            quite the contrary! I really appreciate you taking the time to discuss this and offer your insights!

                             

                            here is a summary of what my app does,

                             

                            1) displays HTML content from my web server using multiple Flex/AIR HTML components

                            2) there is a REFRESH button the user can click to get instant updates from the web server

                            3) there is also a Timer running to initiate the refresh automatically every 30 minutes

                            4) there is another timer that runs to handle the time-out condition if one or more of the HTML components fails to load

                             

                            my goal is to present to the end-user an app that appears to get updates from the server automatically and quickly. ideally I'd love to have this updating every few seconds for near-instantaneous updating. but I think this will be too intensive on the server. and it would be terribly wasteful since the info will rarely be updated more than once or twice a day anyway.

                             

                            so the compromise I am currently using is to check for changes every 30 minutes and make sure that the check is as lightweight as possible. to achieve this I store a lastUpdated value locally and send that for my 30-minute check-in. the server compares that to its own lastUpdated value and if nothing has changed it sends back a brief message indicating no update is needed. on the other hand if the server sees that an update is needed it sends back a list of those HTML resources that have changed and my code then reloads the HTML in those components.

                             

                            I could not figure out how to get the HTML component to reliably report when it fails to load so I needed to build the short Timer routine to trap for errors during the check-in. Ideally if the HTML component had a a fault event like HTTPService I think that would make things easier.