Re:Dropbox traffic infrastructure: Edge network
by SuspiciousSwan on Wednesday October 10, 2018 @03:09PM
(#18187940)
It really depends who your clients are. If they are servers, 30s can work okay. If they are end users, caching happens all over. It's a huge PITA, especially since you'll run into podunk ISPs that have their own custom caching setup, but you have a customer with a shop there. Not that I'm still bitter.
Re:Dropbox traffic infrastructure: Edge network
by SaveTheRbtz on Wednesday October 10, 2018 @03:37PM
(#18188169)
It really depends on the clients, here is an excerpt from the article:
> Here we also need to mention the myriad embedded devices using Dropbox API that range from video cameras to smart fridges which have a tendency of resolving DNS addresses only during power-on.
Re:Dropbox traffic infrastructure: Edge network
by bigiain on Wednesday October 10, 2018 @10:32PM
(#18190630)
> which have a tendency of resolving DNS addresses only during power-on.
Facepalm...
Re:Dropbox traffic infrastructure: Edge network
by aaronblohowiak on Wednesday October 10, 2018 @11:01PM
(#18190712)
DNS TTL is a PITA for us at Netflix as well. We use Zuul to proxy cross-region for TTL "non-responders".
Re:Dropbox traffic infrastructure: Edge network
by tyingq on Wednesday October 10, 2018 @07:59PM
(#18189993)
It would be funny if part of what they are seeing is because the Dropbox client doesn't try reconnects or re-resolving very often.
Re:Dropbox traffic infrastructure: Edge network
by patrickg_zill on Thursday October 11, 2018 @12:53AM
(#18191037)
There's a lot of caching done by e.g. Comcast that does not always honor the TTL.
Interesting, awhile back both Google and AWS engineers replied to a HN thread[1] saying TTL of 30 seconds or so works pretty responsibly and can be trusted and used. Seems to be some disagreement on this.
[1] https://news.ycombinator.com/item?id=17553043