[#1] Dropbox API
Pod newsem o piątym odcinku podcastu AmiWigilia po raz kolejny powstała mała offtopicowa dyskusja na temat Dropboxa dla systemów amigowych. Arti uważa, że zrobienie go jest absolutnie niemożliwe dla nawet najmocniejszych maszyn na których działają systemy amigowe (np. MorphOS na PowerPC G4 1.67GHz). Ja nie mogę zrozumieć dlaczego i dlatego drążę temat. Skoro pełnoprawny klient Dropboxa działa mi wręcz niezauważalnie na starym MacBooku (late 2008) z Core2Duo 2GHz to dlaczego na G4/1.67GHz miałby działać tak koszmarnie dramatycznie? G4 jest wolniejszy od Core2Duo/2GHz ale przecież nie tak bardzo. Skoro coś działa idealnie na tym Core2Duo to w miarę powinno też chodzić na G4.

Myślałem, że może dałoby się zrobić takiego Dropboxa, który byłby synchronizowany na życzenie. Bez śledzenia zmian w chmurze i lokalnych. Nie jestem obeznany z API Dropboxa więc może się zbłaźnię ale chciałbym żeby ktoś (najlepiej Arti) mi uświadomił gdzie tu jest ta niewykonalna część choćby uproszczonego klienta Dropboxa.

Być może przez swoją niewiedzę myślę prymitywnie i nie kumam rzeczy oczywistych ale wyobrażam sobie, że proces synchronizacji przebiega jakoś tak (pomijam cała autoryzację OAuth i zakładam, że już jest zrobiona):

1. Ściągam z Dropboxa JSONa z listą plików, które zostały zmodyfikowane w chmurze od daty ostatniej synchronizacji z tym komputerem.
2. Przeglądam daty modyfikacji plików przechowywanych lokalnie i porównuję je z tym co dostałem z serwera.
3. Jeżeli jakiś plik doszedł lokalnie to go wysyłam do chmury.
4. Jeżeli jakiś plik został lokalnie skasowany to go kasuję w chmurze.
5. Jeżeli jakiś plik doszedł w chmurze to go ściągam.
6. Jeżeli jakiś plik zostął skasowany w chmurze to go kasuję lokalnie.
7. Jeżeli data modyfikacji pliku lokalnego jest nowsza niż tego z chmury to plik wysyłam.
8. Jeżeli data modyfikacji pliku w chmurze jest nowsza niż lokalnego to plik z chmury ściągam i nim zastępuję wersję lokalną.

Czy to wszystko faktycznie jest oparte na datach modyfikacji plików?

Co zrobić z sytuacją gdy oba pliki były modyfikowane i mają dokładnie ten sam czas modyfikacji? :) Jest to sytuacja nieprawdopodobna ale jednak możliwa i trzeba ją wziąć pod uwagę.

Co zrobić gdy data pod MorphOSem jest źle ustawiona? Może się to skończyć dosyć nieszczęśliwie (pokasowaniem w chmurze plików, które były nowsze ale miały starsze daty modyfikacji). Ciekawe jak zachowałby się oficjalny klient Dropboxa gdyby wyłączyć pod OSX/Windows ustawianie czasu z sieci, ustawić datę w przyszłości, zmodyfikować plik, wrócić do normalnej daty. Czy te pliki byłyby traktowane jako nowsze nawet jeżeli te w chmurze byłyby faktycznie nowsze?

Ostatnia aktualizacja: 28.12.2014 18:19:42 przez MDW
[#2] Re: Dropbox API

@MDW, post #1

Modyfikacje plików nie sprawdza się tylko w oparciu o daty a o hash, sumę kontrolną np. poprzez algorytm MD5 lub inny. W przypadku gdy plików jest bardzo dużo to tym kosztowniejsza i bardziej rozciągnięta w czasie jest to operacja.
[#3] Re: Dropbox API

@MDW, post #1

Tak przy okazji w AmigaOS 4.1 (sorry nie wiem jak to wygląda w innych systemach) jest mechanizm notyfikacji w DOSie - można go wykorzystać do śledzenia zmian w systemach plików. Niestety gdy ostatni raz na to patrzyłam miał pewne niewygodne rozwiązania, ale nic czego nie dałoby by się obejść Nie robiłem testów wydajnościowych więc nie wiem jaki wpływ na wydajność systemu na zakładanie notyfikacji na duże systemy plików. Może przy okazji warto to kiedyś zrobić?
[#4] Re: Dropbox API

@MDW, post #1

1. Ściągam z Dropboxa JSONa z listą plików, które zostały zmodyfikowane w chmurze od daty ostatniej synchronizacji z tym komputerem.

I tu już jest problem - ilość zapytań jest mocno limitowana. Nie pamiętam dokładnie jak. Trzebaby doczytać.

Przeglądam daty modyfikacji plików przechowywanych lokalnie i porównuję je z tym co dostałem z serwera.

Na podstawie czego jest tworzona lokalna lista plików?

Czy to wszystko faktycznie jest oparte na datach modyfikacji plików?

Oczywiście, że nie. Dropbox każdy plik hashuje w taki sposób, że później może dociągnąć jedynie jego zmieniony fragment (potrafi sobie porównać dwie wersję w locie. Szczegóły -> binary diff). I to jest to, co głównie wpływa na obciążenie CPU podczas pracy.

Co zrobić z sytuacją gdy oba pliki były modyfikowane i mają dokładnie ten sam czas modyfikacji?

Wcale nie takie rzadkie jak się może wydawać Zwłaszcza jak dwie osoby pracują nad tym samym plików jednocześnie, na dwóch różnych komputerach. Dropbox zapisze oba pliki, w tym jeden jako "conflicted copy".

Co zrobić gdy data pod MorphOSem jest źle ustawiona? Może się to skończyć dosyć nieszczęśliwie (...)[

Tak ale na pewno nie dla Dropboksa. Klient po prostu nie połączy się z chmurą, jeśli data będzie nieprawidłowa. Nie będzie też synchronizował plików, jeśli ktoś umyślnie zmieni datę w trakcie pracy.



Ostatnia aktualizacja: 28.12.2014 18:40:17 przez _arti
[#5] Re: Dropbox API

@grxmrx, post #2

No ok. Załóżmy, że sumy kontrolne pliku lokalnego i pliku w chmurze są inne. Mówi nam to, że któryś z plików został zmodyfikowany. Jednak suma kontrolna nie niesie w sobie informacji, który plik jest ważniejszy/nowszy, który należy ściągnąć/wysłać. Tutaj decyduje tylko czas modyfikacji.

Przed chwilą zrobiłem sobie mały test na oficjalnym kliencie Dropboxa dla OSX. Wyłączyłem synchronizację czasu systemowego z sieci, wyłączyłem sieć, przestawiłem czas 2 dni do przodu, zmodyfikowałem plik na Maku, zmodyfikowałem plik w chmurze pod MorphOSem, wrzuciłem go do Dropboxa (przez OWB) i patrzyłem co się stanie gdy włączę sieć na Maku. Dropbox rozwiązał ten problem dosyć prostacko. Wykrył nierozwiązywalny konflikt i po prostu w Dropboxie były dwa pliki:
- test1.txt
- test1 (maxbook's conflicted copy 2014-12-30).txt

Czyli w przypadku jakichkolwiek problemów z ustaleniem ważności pliku zachowuje się obie wersje ale zmienia się nazwę jednego z z nich. :)
[#6] Re: Dropbox API

@_arti, post #4

I tu już jest problem - ilość zapytań jest mocno limitowana. Nie pamiętam dokładnie jak. Trzebaby doczytać.

A to nie odbywa się jednym zapytaniem na które dostaje się odpowiedź w wielu kawałkach?


Na podstawie czego jest tworzona lokalna lista plików?

No nie wiem. :) Na podstawie dat motyfikacji plików w systemie? :)


Oczywiście, że nie. Dropbox każdy plik hashuje w taki sposób, że później może dociągnąć jedynie jego zmieniony fragment (potrafi sobie porównać dwie wersję w locie. Szczegóły -> binary diff). I to jest to, co głównie wpływa na obciążenie CPU podczas pracy.

Dropbox łączy pliki? Jeżeli w pliku binarnym 100MB zostanie zmieniony jeden bajt to on to "zmerguje" ściągając tylko jeden bajt? Hmmm... mi to wygląda, że zawsze ciągnie całe pliki. :)
No ale mniejsza z tym. Uproszczony klient Dropboxa mógłby po prostu ściągać/wysyłać nowsze pliki. To i tak byłoby 1000 razy lepsze niż pchanie plików przez WWW. :)

Ostatnia aktualizacja: 28.12.2014 18:48:08 przez MDW
[#7] Re: Dropbox API

@MDW, post #6

Nie, DB nigdy nie ciągnie całych plików - tylko zmienione fragmenty. Dwa - nie możesz sobie zrobić "uproszczonego klienta" ot tak. On musi być zgodny z zasadami, na których opiera się cały protokół
[#8] Re: Dropbox API

@_arti, post #7

No ale API pozwala na ściągnięcie i wysłanie pliku. To nie wystarczy? Jeżeli lokalnie podejmę decyzję, że ten plik powinien zastąpić wersję z chmury to mogę go tam wysłać. Przecież tak działa webowa wersja. Tak używam Dropboxa pod OWB w MorphOSie. Wysyłam zmidyfikowany plik o tej samej nazwie i zastępuje on swój odpowiednik w chmurze. Śle się cały plik, a nie kawałek. Tak samo mógłby działać ten uproszczony klient Dropboxa.

Poza tym oo coś to API zostało stworzone. :)
[#9] Re: Dropbox API

@MDW, post #8

Zgadzam się - taki uproszczony klient w oparciu o API to nie powinno być coś ekstremalnie trudnego do implementacji a wręcz przeciwnie.
[#10] Re: Dropbox API

@MDW, post #8

Po HTTP może się to udać ale skoro już tak, to lepiej spiąć prawdziwe konto DB na jakimś komputerze w domu z rsync'iem po stronie MorphOSa... ale, aha, nie ma rsynca pod MOSa
[#11] Re: Dropbox API

@_arti, post #10

To może wykorzystać do tego np. MirrorCopy? Ja codzienne backupy wszystkich partycji MorphOSa na zewnętrzny dysk USB robię przy pomocy MirrorCopy. Analizuje to dwa dyski i synchronizuje listę plików/katalogów tak żeby na obu były identyczne. Robi się więc backup róznicowy i nie jest to tak koszmarnie uciążliwe jak kopiowanie całych partycji (co kiedyś też robiłem co jakiś czas). Dzięki temu nie ma problemu żeby codziennie to robić. W moim przypadku jest to kwestia wsadzenia wtyczki USB do PowerBooka i wybrania jednej opcji z menu górnego Ambienta.
[#12] Re: Dropbox API

@_arti, post #7

Nie, DB nigdy nie ciągnie całych plików - tylko zmienione fragmenty.

Pogrzebałem, poszukałem i wychodzi na to, że faktycznie masz rację.

Tutaj jest napisane coś takiego:

"Before transferring a file, we compare the new file to the previous version and only send the piece of the file that changed. This is called a "binary diff" and works on any file type. Dropbox compresses files (without any loss of data or quality) before transferring them as well. This way, you also never have to worry about Dropbox re-uploading a file or wasting bandwidth."

Czyli wygląda jakby Dropbox nie tylko ściągał kawałki binarnych plików ale jeszcze je kompresował.


Ponadto tutaj wyczytałem też, że Dropbox dla urządzeń mobilnych jest synchronizowany tylko na życzenie:

"Unlike the Dropbox desktop app, which constantly checks your files for changes, the mobile app usually syncs on demand only. This prevents Dropbox from consuming all of your bandwidth and space."


Wobec tego faktycznie takiego prawdziwego klienta, który mógłby konkurować z tymi oficjalnymi zrobić się nie da. Ale taki prymityw do synchronizowania plików po HTTP można byłoby sklecić i odrobinę przybliżyć nas do normalnego świata. :)
[#13] Re: Dropbox API

@MDW, post #1

Dropbox dziala niezauwazalnie w tle na iBook G4 1,42GHz na MacOS 10.5, ktorego uzywam na co dzien.
Wiec nie jest to na pewno kwestia wydajnosci procesora.

Ostatnia aktualizacja: 29.12.2014 12:40:38 przez lekarz_med
[#14] Re: Dropbox API

@lekarz_med, post #13

Wszystko zależy, jak duże pliki i ile z nich na raz synchronizujesz.
[#15] Re: Dropbox API

@_arti, post #14

Jeżeli duże pliki albo dużo plików to po prostu długo się ładuje. Ale żeby jakoś specjalnie obciążało sprzęt to też nie zauważyłem.

A tak przy okazji. Zauważyłem, że jak się tak na codzień używa Dropboxa do niewielkich zmian, wrzuca jakieś kilkumegabajtowe pliki, aktualizuje jakieś drobiazgi typu pliki tekstowe to działa on błyskawicznie. GoogleDrive nie ma do Dropboxa cienia szans. Dropbox reaguje na zmianę dosłownie w tej samej sekundzie i uploaduje plik w mgnieniu oka. GooogleDrive przez następną czasem minutę nawet nie zacznie tego robić. :) Jednak gdy się chce wrzucić na Dropbox kilka GB to trwa to koszmarnie długo. I to nie jest sprawa łącza, bo na tym samym łączu przez np. FTP te kilka GB idzie 100 razy szybciej. I nie przesadzam z tym 100 razy! Może inaczej jest na koncie płatnym ale na darmowym duże pliki to dla Dropboxa absolutnie nieakceptowalny koszmar.

Ostatnia aktualizacja: 29.12.2014 14:22:17 przez MDW
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem