|
Дропбохс ....Сообщение от Voice2001
Ну не нужно всё содержимое смарта на компе видеться. Особо если RW доступ замутил.
---------- Добавлено в 23:22 ---------- Предыдущее сообщение было в 23:21 ----------
Я по SSH гоняют файло. https://play.google.com/store/apps/d...sshdroid&hl=ru
Из сна по сетке телефон будит? или не даёт ему заснуть?
---------- Добавлено в 23:50 ---------- Предыдущее сообщение было в 23:45 ----------
????? оно работает между твоими компами. Если они не в одной локалке - да, будет через интернет. Но тоже только между твоими компами.
При желании можно выключить всё кроме Local Discovery - тогда через интернет не будет синхронизировать.
Последний раз редактировалось lookout; 28.02.2018 в 00:51.
Скачал - выключил. Оно мне нужно раз в месяц. Остальное дропбокс. Иль adb push;
Ну то есть разницы с FTP/SMB никакой :/ для винды только дополнительное неудобство в том, что нельзя зайти штатными средствами. Самба в этом смысле самая удобная..
У дропбокса кстати есть раздражающий минус - он не умеет находить изменения в файлах (21 век блин). Т.е. если в каком-нибудь .sqlite файле под 500 мб была изменена одна строчка - он будет медленно и печально отправлять весь файл.
спасибо, попробую еще раз поковырять
Последний раз редактировалось lookout; 01.03.2018 в 13:55. Причина: перенос
Продаю котят. Недорого. 50р ведро.
А кто умеет? (из мобильных).
Если чо, то это NP задачка. Их много в "21 век блин" переползло из 19....17 веков.
---------- Добавлено в 04:32 ---------- Предыдущее сообщение было в 03:55 ----------
Самое быстрое решение - полное дублирование перед изменениями. Отсылка разности на сервер.
Короче: git commit; git push;
На другом клиенте: git pull;
Но вот что-то не хочется, чтоб на смарте валялся двойной объем mp3/ogg.
Последний раз редактировалось pavlinux; 28.02.2018 в 04:19.
Чё не git?
---------- Добавлено в 21:55 ---------- Предыдущее сообщение было в 21:54 ----------
А, пардоньте, я просто не дочитал ))
BitTorrentSync(Resilio) и его вышеупомянутый опенсорсный аналог Syncthing. Они хешируют файлы кусками и при несовпадении хешей передаётся только изменившийся кусок. Поэтому перед началом синхронизации иногда приходится ждать часами, пока данный хешируются, если папка с сотнями ГБ.
Гит всё же не для того, и он плохо переваривает изменяющиеся бинарники. Побайтовое отслеживание не нужно.
Более того, у Syncthing также есть разные возможности контроля версий при конфликтах и изменениях, от корзины до (по сути) персональной VCS у каждого устройства.
В отличие от торрентов дропбоксе нет необходимости параноить и не доверять своим же дейвайсам, + всегда есть центральный сервер, так что они могли бы упростить процедуру до незаметной.
При аплоаде нового файла
1. Разбиваем его на куски (O(1))
2.1 Начинаем передаём первый кусок, параллельно считаем хеш куска и общий. (фактически O(N) - cкорость хеширования на современных процессорах заведомо превышает скорость чтения и передачи данных, и вообще не грузит цпу, т.к. выполнено отдельным блоком)
Если процессор старый (древний телефон), считаем только общий хеш.
2.2. Как только первый кусок загружен, синхронизируем его везде. Если хеша нет, то его считает самый быстрый девайс из доступных.
2.3 Повторяем 2.1-2.2 пока весь файл не будет загружен, в конце изначальное устройство отправляет общий хеш файла
3. Синхронизирующие устройства сверяют хеши и помечают файл как загруженный. Или помечают его как сбойный и тогда изначально устройство обязано посчитать все хеши самостоятельно (если оно этого уже не сделало), и отправить конфликтующие части повторно.
Если конфликтов нет (99.9(9)% случаев), то общее время не отличается от простого аплоада.
В качестве бонуса - все девайсы получат файл почти мгновенно после завершения передачи, поскольку они могу качать куски файла до того, как он полностью загружены.
При изменении файла
1. Разбиваем на куски
2. Читаем файл и параллельно считаем хеши
3. Продолжая читать файл, ставим в очередь на отравку несовпадающие части.
Общее время - скорость чтения файла или скорость хеширования (которая обычно первышет сотню (или сотни мб)) + передача по сети изменившихся частей.
-----
Нет там ничего принципиально сложного, все части уже тыщу раз обкатаны в торрентах, eDonkey и прочих,, а здесь нужен только упрощённый вариант.
Наверно в дропбоксе просто думают, что не смогут красиво продать эту фичу типичному пользователю, который не поймёт зачем это и о чём речь.
Последний раз редактировалось lookout; 01.03.2018 в 14:00. Причина: перенос
Ну тогда не O(1), а O(N), что равносильно закачке нового файла
---------- Добавлено в 13:30 ---------- Предыдущее сообщение было в 13:28 ----------
Размер блока хэша фиксирован, для перегона одной фотки в 100 кило, хэш тоже будет 1 мегабаб?
Ага, уже исправил. O(1) - в смысле добавленная сложность относительно чтения нулевая. Но да, так нельзя писать )
---------- Добавлено в 13:33 ---------- Предыдущее сообщение было в 13:31 ----------
Насколько я понимаю торренты, файлы бьются на фиксированные блоки типа по 5 мб и для каждого считается хеш. Эти 5 мб монолитны и при ошибке в 1 байте будут перекачиваться всегда 5 мб минимум. Но это чисто мои фантазии и детали реализации можно узнать точнее в гугле ) Можно придумать массу других способов разбить файлы, в зависимости от того, что нужно.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ответить с цитированием