Currently if notifications from server->client fail, the clientside output
looks like:

globusrun-ws -submit -F $host:$port -Ft $scheduler -c /bin/date
Submitting job...Done.
Job ID: uuid:0ba6cc7a-9ee3-11dd-b643-00304827de58
Termination time: 10/21/2008 20:09 GMT
[sits quietly for 3 minutes]
Current job state: Pending

It would be nice if A) the client didn't sit with no messages for 3 minutes and
B) the user was informed that there was probably a firewall blocking
notifications from the server

Maybe something like:
globusrun-ws -submit -F $host:$port -Ft $scheduler -c /bin/date
Submitting job...Done.
Job ID: uuid:0ba6cc7a-9ee3-11dd-b643-00304827de58
Termination time: 10/21/2008 20:09 GMT
Waiting for a notification from the server for up to 300 seconds ...
No notifications received.  Perhaps a firewall is blocking access from $host to
port $portnum on this client?  Switching to polling.
Current job state: Pending

would be more informative?  Users tend to get impatient and just quit the
client during that timeout period because they don't know what's happening. 
Then if they are patient, they don't know how to debug it because they don't
know why they got an answer after the timeout period but not any earlier. 
Telling them that we're waiting, and why it probably didn't work (if it didn't)
seems more helpful.

This came up while debugging LIGO on OSG.