Connection Issues

  • Comments posted to this topic are about the item Connection Issues

  • Living in rural England I know this only too well...and there are a lot of places a LOT worse off than I am.

    Microsoft (MS) found this when they were going to release Xbox One with a mandatory "always connected" setup. Great if you are on MS' campus. I also doubt that they have cell phone connectivity issues there either.

    MS is no worse than so many other companies. You only have to look at how much software just balks at low connection speeds and is useless with none.

    Problems when travelling and haven't paid for the hotel Wi-Fi? Pah! Try living that way!!!

    (How's the connectivity at the ranch Steve?)

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I think Steve has made a really interesting observation. "Always on" is not necessarily a good idea. Software which really depends on communication is one thing, but creating such a dependency because "something might want to connect" is poor design and, as Steve points out, can harm performance.

    There are plenty of places in the world where network access is not as reliable, or as fast, as we would all like. And there are also good reasons why one might not want to connect a system to the internet (privacy, security, it's only going to exist for a few days, bone-idleness...). Isolated, stand-alone systems have a place and the designers of systems software really shouldn't assume they know better.

    I'm not sure that I know exactly how I want to fix this. I don't want to have to answer lots of configuration questions either!

    Anyway, I will try and remember this as a possible cause when something which worked ok when it was connected works less well when it is disconnected, or for that matter, the other way around.

    Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]

  • Interesting thought. I need to go check on some code now. Thanks.

  • I realize this is off topic, but the question of the day today has two correct answers (for radio buttons) and both answers appear to be identical. OK, sorry for the interruption.

  • An additional point is that we should not be scathing that a system can try to access online facilities but it should be both configurable and a background task to ensure that it does not slow down the system.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • First, a technical option:

    What happens if you put a firewall in between set to Reject all access to the internet, so at least there's a very fast response to any query to the internet, even if the response is that the packet was rejected? You'd at least have a chance at avoiding timeouts.

    Second, an opinion:

    I HATE developers who write apps that communicate more than is required for the core functionality (which is often not at all). They don't need to know when I turn on their app, or how I use it, or what I type in it, or what other apps are running, or when I get a phone call, or if my computer runs a web server, etc. etc. Further, every single Internet communication, whether sending a packet out or opening a socket to accept connections, is another major security hole.

    I just got though troubleshooting something - my home SNORT instance had been blocking another app because that app was trying to connect via POODLE-vulnerable SSLv3; nothing to do but wait until the app's upgraded, since that is the core functionality of the app; that's a security hole I'm not willing to allow.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply