Without being continuously connected to the network, how can I protect from Double Spend attacks? I'm a vendor who is interested in protecting myself from double spend attacks.

What software, configuration, connectivity, or timeout is required to mitigate this risk?

Namely, how would I protect myself if a continential communications blackout were to occur, as described here.

This could occur if I'm accepting payment on a satellite link, as often occurs on boat-casinos, islands (Hawaii), or in 3rd world countries.
To essentially eliminate any risk due to double spending, the recommended level of confirmations is six.

For most transactions such as those to a bricks and mortar merchant, payment might be accepted immediately (with 0 confirmations), but that exposes the merchant to a small degree of double-spending risk.

A recommendation for merchants running their own node is to have the configuration where there are no incoming connection and to explicitly have an outgoing connection to a well-connected node.  

Thus, properly configured this way, the merchant is not much at risk of double spending because either the transaction was broadcast and it reached the well-connected node that the merchant connects to or it didn't and the merchant doesn't know about it until communications from the party attempting to pay can be re-established with the outside world.

In that scenario, bitcoin fares no worse than any other merchant payment system as those require authorization from connected sources as well.

The amount of data to receive blockchain data is relatively little -- under 100MB per day.  Thus even a single dialup modem connection is all that would be needed and that node could then serve all other nodes connected locally.

Additionally, if mobile communications are present, the merchant could simply use mobile notification from a hosted service and not run using a node at all. 

There is a business solution not a technical one to the specific scenario requested.  Just as a hotel will accept a check from a guest even when it doesn't have a guarantee that the check won't bounce, a merchant can accept a bitcoin transaction even when there are no communications by adding a layer above (e.g., verifying identification, getting approval to charge against a backup payment method using a credit card, not selling anything of high value during the communications outage, etc.)