Pull to refresh

Comments 38

Ещё был ReGet и если я правильно помню Флешгет появился после него.
Помнится Reget была самой крутой, пока не появился рекламный DM.
Это была единственная программа, на которую я купил лицензию в студенческие года. На Dialup'e от Кировэлектросвязи образца начала 2000-х оно того стоило.
У меня денег не было )) Я помню, что просил разработчика trashreg сделать мне лоадер, который сам нажимает кнопку «продолжить» ориентируясь по расстоянию белых пикселей в кнопках загрузочного экрана. Тогда я был горд своей идеей )
Я со стипендии покупал :)
Хотя лоадер тоже делать доводилось. Для Windows Commander (тогда он ещё так назывался). Делал в небезызвестной в то время программе InqSoft Sign of Misery.
Ох, вспомнил как две недели качал Ultima Online по ночам со скоростью 19,2 )))
а можно подсунуть этой проге несколько зеркал на файл? Это была бы классная фича, если ссылка динамическая и живет например всего один день, а закачка по каким либо причинам прервалась(например комп выключили).
Такую возможность я не предусматривал. Но в файле настроек который хранится в вашей домашней дирректории (.godownload) вы можете подредактировать список закачек и сделать две закачки указывающие на один файл в который нужно писать, но с разными адресами и разными дипазонами данных. Это конечно не рабочее решение, а попробовать как вы выразились подсунуть.
b означает «бит»
B означает «байт»

В вашей программе вы похоже имели ввиду байты, а не биты.
Это не всё. Ещё и скорость прочему-то в единицах количества информации, а не собственно скорости. Вероятно там должно быть Mb/sec, а не Mb. А может быть даже и MB/sec, в случае скорости гораздо сложнее угадать мегабиты/сек или мегабайты/сек на самом деле имел ввиду автор.

Указывание почти случайного набора символов — поразительно распространённая ошибка. Казалось бы не орфография, ошибка в единицах измерения кардинально меняет смысл текста. Не понимаю, почему люди за собой не проверяют.
<Зануда_мод_он>
Еще возможно автор имел ввиду MiB, поскольку MB = 1 000 000байт, а не 1 048 576, как многие полагают. Если уж совсем придираться.
Могу порекомендовать первым делать слать HEAD запрос.
Узнаете и размер файла в «Content-Length», и возможность докачки в «Accept-Ranges».
Чтобы узнать правильный размер и указать его в Range в первом «качающем» запросе.
После вот этой уязвимости на веб серверах могут быть настройки, отбрасывающие запросы с некорректным range.
Не нужно всё это. Вы предлагаете лишний запрос и ничего взамен.
Варианты.
1)мы качаем с самого начала
не важно поддерживается что-то сервером или нет — мы получим в ответ на GET всё что нужно, никакой range указывать не нужно.
2) мы качаем не с самого начала
в ответе сервера мы получим достаточно информации о том, с какого места на самом деле мы продолжаем качать.
> в ответе сервера мы получим достаточно информации о том, с какого места на самом деле мы продолжаем качать.

Вот тут поподробнее, пожалуйста
Всё то что вы ожидаете получить в HEAD придёт и в GET.
Пришел только размер без range или вообще без размера и диапазона? значит качаем с нулевого байта
Пришел рэнж — ну сами понимаете.
HEAD нужен только если вы не собираетесь качать, а вам нужно, например, кэши посбрасывать, или статистику пособирать.
Обновление интерфейса осуществляется каждые 500 милисекунд.


Почему бы не заюзать Websockets и делать push с сервера?
ubuntu, отредактировал юзера и группу, выполнил sh /home/rei/download/godownload/Ubuntu/install.sh

cp: не удалось выполнить stat для «./godownload»: Нет такого файла или каталога

вы сначала перейдите в дирректорию и от туда запустите.
cd /home/rei/download/godownload/Ubuntu/
./install.sh
От подобных проблем в скриптах помогает переход в папку где лежит сам скрипт, тут хорошо описано как это сделать.
UFO just landed and posted this here
С другой стороны, слишком много параллельных потоков закачки тоже плохо — вырастает служебный трафик, что приводит к уменьшению полезной пропускной способности


1. А почему должен возрасти служебный трафик, можно подробнее?

2. Статья о реализации на Go, а в Go потоки — это не совсем потоки… или даже совсем не потоки.
Все правильно он написал. Но на прикладном уровне что имеем то и имеем.
Отвечу на ваши вопросы:
1. Поясню на примере: Вот где больше топлива потратится если 100 человек на одном автобусе перевезти или в 5 газелях. Естестсвенно в пробке быстрее газели проедут, но без пробки одинаково, но бензина потратится больше 5 газелями.
2. Вы наверное путаете потоки выполнения и потоки скачивания, одно это параллельные нити выполнения программы, а другое tcp-ip соединения.
UFO just landed and posted this here
В данной статье автор просто обновлял данные каждые n секунд, хотя можно было бы и websocket'ы использовать, тогда был бы чистый realtime (медленнее на константу, чем если бы это была обычная программа с графическим интерфейсом, из-за обработки пакетов в сетевом стеке).

По поводу speedtest'a, iperf, btest и прочих, я видимо не очень хорошо объяснил, демон реализующий логику программы крутится на тойже машине, что и открывают браузер (хотя это и не обязательно). Браузер в данном случае как Xorg, он просто позволяет представить данные графически, а элементы управления позволяют передать управляющее воздействие в демон, чтобы тот выполнил какое-то действие.
У меня есть мечта, чтобы все программы работали именно по такой схеме как у вас: вычислительная часть — сервис, а визуальная — браузер. Тогда вычислительную часть будет легче сделать кроссплатформенной, а визуальную за счет JS-ных фреймворков (EmberJs, AngularJs и т.д.), CSS, HTML, а так же WebSocket'ов намного более динамичной, живой, красивой.
Ну я не знаю как других новых языках (rust, scala....). Но мне кажется, что go реализовывался с прицелом на подобного рода интерфейсы. Он уже из коробки имеет http-сервер и json-парсинг и тд.
Когда go только появился, я очень растроился так как не нашел визуального toolkit для него, кнопочки и окошки не поделаешь. Потом понял что не так уж он и нужен. Хотя если появится я точно не растроюсь)
Уже достаточно долгое время все свои сервисы на go я делаю по одной схеме. Как правило, web-интерейс через который пользователь взаимодействует с json-сервисом посредствам http-запросов. Такая схема работы дает ряд преимуществ перед традиционными графическими интерейсами


Очень хотелось бы об этой технике почитать (обсудить) подробнее.
Отдельной статьёй (это в порядке дружественной подсказки автору) и на примере простого и компактного приложения, которое легко обозреть… в 10 минут.
Потому что все составляющие компоненты известны и понятны, но интересно бы посмотреть как автор их увязывает в комплекс.
Ну вот смотрите я тут об этом писал на примере «Диспечера задач для linux» и «Dicom-клиента».
habrahabr.ru/post/247727
habrahabr.ru/post/254581
Я бы наверное написал отдельную микростатью, но тут просто схема работы (Интерфейс отдельно <->логика отдельно). Не думаю что она достойна отдельной статии.
У меня был мысль реализовать визуальную-библиотеку-конструктор, которая связывала событийной моделью веб-интерфейс и обработчики событий который уже на GO.
Что то на подобие визуального редактора как у Visual studio. OnClick() OnMove() и тд.
Но чето я прикинул что опыта маловато. Надоже как-то компилировать текст разметки в исходный код go.
У меня был мысль реализовать визуальную-библиотеку-конструктор, которая связывала событийной моделью веб-интерфейс и обработчики событий который уже на GO.

Интересно это применительно не только к Go, но и к любому другому языку программирования.

Что то на подобие визуального редактора как у Visual studio.

Какой ужас! o-:
Под linux, и вроде mac, есть утилита aria2c, множество параметров и поддерживает множество источников, втч торренты, пользуюсьсть с консоли, но есть web-ui
Sign up to leave a comment.

Articles