Jaką strategię pobierania plików wybrać?

Aplikacja - w skrócie "czytnik ebooków", musi pobrać około 20000 dokumentów, o łącznej objętości 20GB. Platforma iOS.
Jakie podejście wybrać:

1. Backend przygotowuje kilka dużych paczek, całość odbywa się w kilku callach do jakiejś usługi chmurowej
2. Wiele (np. 20000...) żądań o pojedyncze kawałki, przeprowadzonych równolegle (kilka wątków)

Osobiście skłaniam się ku podejściu #2, bo daje lepszą kontrolę nad tym co zostaje pobrane jako pierwsze. Pytanie, czy są jakieś ograniczenia iOS, o które można się przy takim podejściu rozbić. Chciałbym tez uwzględnić pobieranie danych w tle.
Podpowiecie coś?

A musisz koniecznie od razu pobierać te 20k dokumentów? Może wystarczy wystawić jakiegoś endpointa na backendzie który zwraca listę dostępnych dokumentów (+paginacja aby doczytywać metadane dopiero po zeskrolowaniu w dół widoku) i pobierać konkretny plik dopiero po wybraniu go z UI.

@MrMadMatt: No muszę. Te treści muszą być dostępne offline.

Możesz jedną podstawową dużą paczkę książek zrobić, a jak będą nowe dochodzić to resztę już na bieżąco sobie dociągną + jakaś lista książek, żeby kontrolować jakie już mamy.
W razie gdyby ktoś nie chciał wszystkich to zawsze możliwość pobrania pojedynczej książki bez całego zipa, jeszcze dochodzi opcja kompresji na zawołanie przez serwer określonej ilości plików, ale wtedy ktoś może nadużywać tego bo będzie istniała bardzo duża liczba kombinacji z jaką można utworzyć archwium, serwer wyłożyć DOS'em.

Teoretycznie istnieje sposób przesyłania wielu plików jednym zapytaniem z kompresją czy bez jak do jednego pliku, jak przy uploadowaniu `Content-type: multipart/form-data', da się tak w drugą stronę też wysłać, ale nie mam pojęcia czy przeglądarka jest w stanie bezproblemowo sobie poradzić, czy ręcznie trzeba będzie przeparsować, w końcu http to zwykły tekstowy protokół, nie koniecznie to będzie szybkie.

Można też dać użytkownikowi możliwość wybrania jakie książki chce sobie zassać, nikt przecież 10 jednego dnia nie przeczyta, async czy thready powinny być spoko, większość czasu chyba i tak będzie się czekało aż pakiety dotrą, chyba że jeden duży to praktycznie cały czas będzie obsługiwane.

Też można jakiś inny protokół rozważyć komunikacji jeśli byśmy chcieli synchronizować zawartość katalogu u clienta z zawartością serwera.

Bardziej zastanawiam się, czy pobieranie dużej liczby małych plików w kilku wątkach (bo czekanie...) nie spowoduje, że system nałoży jakieś kary wydajności, przepustowości itp. Jeżeli to możliwe, chciałbym też mieć coś takiego robione w tle, w sensie iPad sobie leży na ładowarce, a co ma zostać pobrane, to zostaje pobrane.

Czekanie w wątku to po prostu oddanie czasu procesora do kernela, chyba że to spin lock wtedy cały czas thread chodzi na full obrotach.

Nie ma co się za dużo zastanawiać, pobierz listę plików, potem zrób generator adres/+ nazwa pliku.

Później jakieś testy typu pojedynczy async connection, czy jeden thread i w for pobierasz te pliki z serwera, patrzysz jak to chodzi.
Później testujesz jakieś gather po 10 async połączeń lub poole threadów.

Serwer jak jest typu nginx to on tam może wykonać pobranie z dysku pliku, kompresję i umieszczenie w ramie, cache dla przyszłych połączeń, żeby z dysku nie zasysać.

Pobieranie po jednym pliku tak robi np. android sklep, gdyż jeśli serwer udostępnia upload o większym speedzie niż download użytkownika to i tak może wysaturować mu cały dostępny download i pobierać plik z maksymalną dostępną prędkością jaką mu tam dostawca oferuje, wtedy jak dwa pobiera pliki na raz to po prostu każdy pobiera połową prędkości, to na to samo wychodzi.
Jedynie jeśli pliki są bardzo małe czyli jak robisz gole http requesty to wtedy raczej lepiej wiele asynchronicznych połączeń robić, bo i tak nigdy nie wysaturujesz całej prędkości internetu.

Sam nie wiem, lepszego sposobu niż sprawdzenie różnych przypadków chyba nie będzie.

piotrpo napisał(a):

Podpowiecie coś?

Przemiel te dokumenty do jakiegoś strawnego formatu (np. DjVu) zrasteryzuj do progresywnego JPEG i pobieraj sekwencyjnie. Większość ludzi ma mniejszą lub większą wadę wzroku ale są za to bardzo niecierpliwi.

Tak więc nie zauważą że np. litery są rozmyte ale za to na pewno się wk***ą że muszą czekać na download 20 GB. A tak masz jedno połączenie, jeden wątek i ciągłą poprawę jakości!