|
|
|
|
|
|
by morsch
2301 days ago
|
|
|
Published keys are 16 bytes, one for each day. If moderate numbers of smartphone users are infected in any given week, that's 100s of MBs for all phones to DL. That seems untenable. It's a lot, but untenable? If 300 million report as infected, that's 4.8 GB, coincidently the size of a DVD. So 2 hours of Netflix, 1 hour at 4k. Very easy to cache this data close to the edge, too. |
|
|
> That seems untenable.*
> It's a lot, but untenable? If 300 million report as infected, that's 4.8 GB, coincidently the size of a DVD. So 2 hours of Netflix, 1 hour at 4k. Very easy to cache this data close to the edge, too.
Just doing the math here, assuming a perfectly efficient wire protocol was used, each infected person would amount to (16 x 14 = 224 bytes) of data to be transmitted.
Assuming we see 150k new cases per day, worldwide (worldometers is reporting 100k new cases per day as the peak, and let's factor in 50% margin), this would be 33.6 MB of data per day.
Since you only need to transmit that day's data rather than the full database, a very basic sync protocol could be used here - the phone simply stores the sequence number of the last identifier handled, and it can be given subsequent data. This could even be done with a static (and thus cacheable) server if cases are chunked sequentially into 1MB chunks, and addressed by filename based on the last case ID.
For clarity here, case ID would be simply be the sequential number that a given tracing ID has in the server-side record, so you only need to fetch data you haven't already checked against.