[TAP] sync vs async - time outs

[Markus Demleitner]

On Wed, Mar 04, 2009 at 10:13:05AM +0000, Guy Rixon wrote:
> Perhaps a mapping campaign is needed. if we can work out the
> minimum timeout that is generally imposed by the network -
> a sort of worse-probable value - then we can say to TAP implementors
> "make it work faster than this in all cases or you need an async mode".

While I trust interesting results can be expected, I don't think this
can help with implementation guidelines.  The most restrictive
components will generally be at the edges, either proxies the server
is behind or proxies the client is behind.  You won't catch extreme
cases of those.

Clients will have to handle queries failing in all kinds of ways
(doing a random All-VO-query on VOExplorer at any given time
emphasises this fact); the net connection may be down (or go down
between two async requests), the servers may be down, DNS records may
be botched, the cable may drop excessive amounts of packets, etc.
Timeouts imposed on connections are just another thing that may
happen when you talk to something at the other end of the internet.

While I'm talking about timeout: I also think that "controlled"
timeouts on the queried servers are important, mostly for reasons
Gerard has hinted at -- with today's machines, I'd have serious
doubts that a query that was not crafted for a particular site and
runs for more five seconds does something intended by the user.
Thus, on my system people have to manually specify timeouts of more
than five seconds if they want this.

All this leads me to believe that having a formalized TIMEOUT
parameter and a corresponding controlled error message ("TIMEOUT"
analoguos to "OVERFLOW", say) would be a good thing and probably easy
to implement on both server (where you'll want *some* kind of timeout
anyway and would then have a guideline what to do when a timeout
occurs) and client (where it's just another parameter, or just
another error message to present to the user, again analoguos to
OVERFLOW).

True, this may not be as important in /async as according to UWS
(that lets you cancel jobs).  But again, it's at least an order of
magnitude easier to implement.

Cheers,

          Markus