javascript-opentimestamps
javascript-opentimestamps copied to clipboard
opentimestamps
Slow server delays timestamping
Currently one of the default calendar servers is down: https://a.pool.eternitywall.com. It takes a long time to load, and when it eventually does, it returns a 504 error. Unfortunately this long loading time seems to delay the whole timestamping process. I could only fix the delay by removing it from the calendar list.
To me this is unexpected behaviour. I would expect a maximum timeout for all calendars to respond of 1-2 seconds, and that would only be exceeded if two calendars (or whatever the user's requirement was) hadn't responded yet. In my case this would solve the delay problem, since 3 out of the four default calendars are working at a regular speed.
https://a.pool.eternitywall.com/ is working now, sorry.
I agree having options to consider a timestamp good with N requests, or having a lower timeout would make sense
Maybe we need two timeouts? A shorter "wait for every calendar" timeout and a longer "wait for minimum # of calendars" timeout?
Not sure how we should communicate this to the user though. Need good names. We may also want the second timeout to be an additional timeout on top of the first one, rather than two separate absolute timeouts.
In my mind there would be a timer for each calendar, something like max_response_time. If that timer went off before the calendar had finished sending its response, then the request would either be cancelled, or defer to the "min # of calendars timer" , depending on if the minimum # of calendars had responded yet. Maybe this is the same as what you described, although "wait for every calendar" makes me think the calendar request are sequential, which I don't think is true.
@makew0rld The tricky thing is the timeout I'm talking about is basically a two step: 1) wait a little bit to try to get timestamps from every calendar, 2) wait even longer to try to at least get a valid timestamp.
Maybe we could just reduce the timeout a bit, eg to 3 seconds? That way we'd continue to have a single, easy to understand, timeout. Though users on very slow connections might have to manually increase it.
My point is that it makes sense to time each calendar request individually, to prevent individual slow servers from slowing everything down even if the minimal number of servers have already responded.
Reducing the timeout would also work, but be less effective in certain situations as it fails to differentiate between one specific server being slow/down, or the whole network being slow.
On August 3, 2023 5:01:23 PM GMT+02:00, makeworld @.***> wrote:
My point is that it makes sense to time each calendar request individually, to prevent individual slow servers from slowing everything down even if the minimal number of servers have already responded.
Reducing the timeout would also work, but be less effective in certain situations as it fails to differentiate between one specific server being slow/down, or the whole network being slow.
I think you're understanding of this may be incorrect: the requests are sent in parallel. So the only way a slow request affects the overall time is via the timeout waiting for a response. The timeouts are already individual, in the sense that each request is associated with its own timeout, set at the same time to the same value.
Thanks. I think reducing the current single timeout covers most use cases. My only remaining point is that it doesn't cover the use case of a user on an unreliable network. That user would want long timeout for responses (as sometimes their network is slow) but would want to end quickly if the min. number of responses had been reached. These seems to require two timeouts.
That is not my situation however, and so reducing the timeout is a good situation for me personally.