7 Кб, 200x200Всем привет, возникла такая проблема, что надо перекинуть около 100гб инфы на другой комп (удаленно), все облачные хранилища платный и т.д, есть какой-то бесплатный аналог? Или как проще перекинуть эти данные:?
dc++, торрентом.
>>81341 (OP)
Ставишь с обеих сторон Syncthing, проверяешь, возможна ли прямая связь через NAT. Если нет — пользуешься его публичными перекладными серверами. Если медленно — не жалуйся, их держат такие же энтузиасты, и не требуют денег.
Ещё тривиально оплатить самую дохлую виртуалку без лимита трафика на минимальный срок и передать через неё (например, настроив свой VPN- или TURN-сервер), но если бы ты понимал, как просто это делается, ты бы не спрашивал.
Ставишь с обеих сторон Syncthing, проверяешь, возможна ли прямая связь через NAT. Если нет — пользуешься его публичными перекладными серверами. Если медленно — не жалуйся, их держат такие же энтузиасты, и не требуют денег.
Ещё тривиально оплатить самую дохлую виртуалку без лимита трафика на минимальный срок и передать через неё (например, настроив свой VPN- или TURN-сервер), но если бы ты понимал, как просто это делается, ты бы не спрашивал.
>>81647
Или по 1440 КБ через дискеты.
Или по 1440 КБ через дискеты.
>>81341 (OP)
Прост ставишь syncthing. Ничё там с натами выдумывать не надо. Само поедет.
Прост ставишь syncthing. Ничё там с натами выдумывать не надо. Само поедет.
>>81344
Сука каждый раз охуеваю с этих советчиков.
Поднять свой домен на белом айпишники задача в десять раз сложнее чем через этот белый айпишник передать файл, неважно хоть по nextcloud, хоть по ftp, хоть по smb.
>Nextcloud
Сука каждый раз охуеваю с этих советчиков.
Поднять свой домен на белом айпишники задача в десять раз сложнее чем через этот белый айпишник передать файл, неважно хоть по nextcloud, хоть по ftp, хоть по smb.
>>81677
«Само» оно поедет со скоростью публичного ретранслятора, а там быстрее 100 мегабит единицы работают:
https://relays.syncthing.net/
А если удастся обдурить NAT и связаться напрямую, потенциально всю обещанную провайдерами с обеих концов пропускную способность можно загрузить.
Впрочем, если оп хотел, то за прошедшее время уже передал свои 100 ГБ, даже медленным способом. Не так это и много сегодня, вон, игрульки к этой отметке подбираются.
«Само» оно поедет со скоростью публичного ретранслятора, а там быстрее 100 мегабит единицы работают:
https://relays.syncthing.net/
А если удастся обдурить NAT и связаться напрямую, потенциально всю обещанную провайдерами с обеих концов пропускную способность можно загрузить.
Впрочем, если оп хотел, то за прошедшее время уже передал свои 100 ГБ, даже медленным способом. Не так это и много сегодня, вон, игрульки к этой отметке подбираются.
>>81690
Оно стуном поженится 90%. Да даже если не поженится, релей на пару MB/s прососёт файл за несколько часов.
В любом случае это всё та инфа про которую ему не надо думать.
Оно стуном поженится 90%. Да даже если не поженится, релей на пару MB/s прососёт файл за несколько часов.
В любом случае это всё та инфа про которую ему не надо думать.
get things from one computer to another, safely
https://github.com/magic-wormhole/magic-wormhole
https://github.com/magic-wormhole/magic-wormhole
>>82354
Тут ничего оригинального для нашей задачи нет, всё так же используется запасной публичный сервер на всякий случай. Только в этом приложении это один сервер одного чувака, который его держит за идею. Например, если он примется наводить там порядок, неудачливым пользователям придётся подождать, пока профилактика не закончится.
Вообще, цель проекта не в передаче данных по сети (что нового можно тут изобрести?), а в демонстрации криптографической схемы, в которой промежуточный сервер (анонсирующий клиентов друг другу) не видит, что делают участники, и гарантированно не может им ничего подменить, так что доверять ему не требуется, и в создании коротких и удобных для передачи секретов.
Стоило бы дать ссылку на совместимые клиенты:
https://magic-wormhole.readthedocs.io/en/latest/ecosystem.html
Например, прямо в ГНУМЕ есть простое окошечко для простого народа:
https://apps.gnome.org/ru/Warp/
Заметим, что они всё так же пользуются сервером по умолчанию:
https://gitlab.gnome.org/World/warp/-/blob/main/src/globals.rs?ref_type=heads
Деды из Debian по крайней мере почесали в затылке и добавили свой защитный краник, чтобы в случае взрывной популярности можно было перенаправить трафик на собственный вспомогательный сервер.
https://sources.debian.org/patches/magic-wormhole/0.9.1-1/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850015
Также стоило бы дочитать до того момента, где описывается, что в протоколе первой версии передача нескольких файлов организована путём сжатия их в архив (и не на лету при отправке, как можно было бы подумать), а новый сложный протокол «для всего» в бесконечной разработке. Архивировать 100 ГБ? Ха! Конечно, мастера линукса могут придумать, как слепить из выбранных файлов и каталогов виртуальную файловую систему, а потом представить её саму в виде файла, который программа может «просто читать», но такие люди и через netcat всё передадут.
Тут ничего оригинального для нашей задачи нет, всё так же используется запасной публичный сервер на всякий случай. Только в этом приложении это один сервер одного чувака, который его держит за идею. Например, если он примется наводить там порядок, неудачливым пользователям придётся подождать, пока профилактика не закончится.
Вообще, цель проекта не в передаче данных по сети (что нового можно тут изобрести?), а в демонстрации криптографической схемы, в которой промежуточный сервер (анонсирующий клиентов друг другу) не видит, что делают участники, и гарантированно не может им ничего подменить, так что доверять ему не требуется, и в создании коротких и удобных для передачи секретов.
Стоило бы дать ссылку на совместимые клиенты:
https://magic-wormhole.readthedocs.io/en/latest/ecosystem.html
Например, прямо в ГНУМЕ есть простое окошечко для простого народа:
https://apps.gnome.org/ru/Warp/
Заметим, что они всё так же пользуются сервером по умолчанию:
https://gitlab.gnome.org/World/warp/-/blob/main/src/globals.rs?ref_type=heads
Деды из Debian по крайней мере почесали в затылке и добавили свой защитный краник, чтобы в случае взрывной популярности можно было перенаправить трафик на собственный вспомогательный сервер.
https://sources.debian.org/patches/magic-wormhole/0.9.1-1/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850015
Также стоило бы дочитать до того момента, где описывается, что в протоколе первой версии передача нескольких файлов организована путём сжатия их в архив (и не на лету при отправке, как можно было бы подумать), а новый сложный протокол «для всего» в бесконечной разработке. Архивировать 100 ГБ? Ха! Конечно, мастера линукса могут придумать, как слепить из выбранных файлов и каталогов виртуальную файловую систему, а потом представить её саму в виде файла, который программа может «просто читать», но такие люди и через netcat всё передадут.
>>96999
А ты в деталях процесс представь.
Если мы хотим полностью приватный торрент, то ни трекерами, ни DHT пользоваться не можем, и должны и передавать сам торрент-файл (по не публичному каналу, что исключает соцсеточки), и добавлять пиров руками с обеих сторон (как-то узнав точный внешний порт). Те, кто понимает, как это всё работает, не будут задавать такие простые вопросы.
Если мы ослабляем требования и будем приглядывать за тем, что чужих соединений не происходит (или названия файлов раскрыть случайно не страшно), то можно и DHT с открытыми трекерами использовать, а передавать обычную магнитную ссылку. Или можно сделать приватный торрент, но с любым публичным трекером в качестве места встречи.
Проблема всегда одна для любых программ: если пара пользователей сидит за NAT, не позволяющими им соединиться ни в одну сторону, то ничего не будет работать без третьей стороны, доступной обоим. Торрент-клиенты сами по себе ничего не могут с этим сделать (если не использовать друга или покупать сидбокс, что обнуляет приватность), а вот приложения для синхронизации либо содержат какие-то сервера, либо позволяют их указать.
А ты в деталях процесс представь.
Если мы хотим полностью приватный торрент, то ни трекерами, ни DHT пользоваться не можем, и должны и передавать сам торрент-файл (по не публичному каналу, что исключает соцсеточки), и добавлять пиров руками с обеих сторон (как-то узнав точный внешний порт). Те, кто понимает, как это всё работает, не будут задавать такие простые вопросы.
Если мы ослабляем требования и будем приглядывать за тем, что чужих соединений не происходит (или названия файлов раскрыть случайно не страшно), то можно и DHT с открытыми трекерами использовать, а передавать обычную магнитную ссылку. Или можно сделать приватный торрент, но с любым публичным трекером в качестве места встречи.
Проблема всегда одна для любых программ: если пара пользователей сидит за NAT, не позволяющими им соединиться ни в одну сторону, то ничего не будет работать без третьей стороны, доступной обоим. Торрент-клиенты сами по себе ничего не могут с этим сделать (если не использовать друга или покупать сидбокс, что обнуляет приватность), а вот приложения для синхронизации либо содержат какие-то сервера, либо позволяют их указать.
>>97014
Зашифровать говно в архив, че мозга ебать.
Зашифровать говно в архив, че мозга ебать.
>>97014
Чем такой хуйней заниматься лучше впн туннель поднять между двумя сторонами. Есть сервисы позволяющие сделать это даже если оба сидят за Натом, типа зиротира. Внутри туннеля файлы как угодно можно передать
Чем такой хуйней заниматься лучше впн туннель поднять между двумя сторонами. Есть сервисы позволяющие сделать это даже если оба сидят за Натом, типа зиротира. Внутри туннеля файлы как угодно можно передать