LINUX.ORG.RU

Нужен совет

 , , ,


0

0

Есть идея написать проект шаринг-демона под никс. Давайте поясню что это такое и с чем это кушать: У меня дома стоит файл сервер раздаёт по фтп (pureftpd), дц++ (microdc2), торренты (transmission-cli). для каждого протокола стоит свой сервер, но мало того - эти сервера дают мало возможностей как по мониторингу так и по администрированию.

У меня родилась идея написать демона, который физически состоит из 4 частей - ftp-sharingd, dc-sharingd, torrent-sharingd и master-sharingd (контроль, мониторинг, веб интерфейс). Демон разделён на 4 части руководствуясь UNIX-way.

Одновременно хотелось бы овладеть ещё одним языком, из кандидатов: D, Vala либо Scala/Groovy


Нужен совет

> Одновременно хотелось бы овладеть ещё одним языком, из кандидатов: D, Vala либо Scala/Groovy

Кандидаты не в тему, разве что D.

const86 ★★★★★ ()

Нужен совет

за исключением каналов, по сравнению с D язык go — убогий отстой, думаю каналы на D тоже можно написать

Scala/Groovy на одну доску нельзя ставить, из них однозначно Scala

вопрос Scala vs. D легко не решается

_________________________________________

вообще проще всего написать просто тулзу для мониторинга и администрирования, т.к. свои реализации именно протоколов тебе ничего не дадут

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от www_linux_org_ru

Нужен совет

Ну эти демоны просто не обладают всем необходим мне функционалом. Лично правил microdc2 для активного режима через портфорвардинг (чтобы отправлял хабу при ConnectToMe не ip с интерфейса, а ip указанный в конфиге) - откровенно говоря весьма весьма говнокод.

sig_11 ()
Ответ на: Нужен совет от dimon555

Нужен совет

Важно что бы это были интероперабельные демоны, и достаточно функциональные. Те что я использую сейчас - весьма убоги, возможно есть лучшие варианты.

sig_11 ()
Ответ на: Нужен совет от sig_11

Нужен совет

> Важно что бы это были интероперабельные демоны, и достаточно функциональные. Те что я использую сейчас - весьма убоги, возможно есть лучшие варианты.

Если ты отвяжешь комбайны типа dc++ от гуя, это будет замечательно.

Вопрос только как им отдавать синхронные команды (ну это видимо пайп и команды на человеко-понятном языке, как сделано в amule), отдавать асинхронные команды и получать прогресс (в амуле этого не осилили, там есть другой костыль).

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от www_linux_org_ru

Нужен совет

* пайп в том смысле, что amulecmd работает не только с консоли, но и через пайп do_something.pl args | amulecmd | process_output.pl а не в том смысле, что через пайп работает amule -f

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от www_linux_org_ru

Нужен совет

Планируется что демоны будут либо слушать на определённом порту команды, либо коннектится к мастер-демону. Для команд планирую использовать либо json либо xml либо выдумывать свой бинарный формат

Хороший пример как сделано - это ISC dhcpd (omshell)

sig_11 ()
Ответ на: Нужен совет от sig_11

Нужен совет

> Для команд планирую использовать либо json либо xml либо выдумывать свой бинарный формат

высказываюсь за бинарный, т.к. на высоких скоростях дофига будет трафика «кусочек файла ... получен», экономия на преобразованиях туда-сюда весьма существенна особенно для слабого проца

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от www_linux_org_ru

Нужен совет

сорри, я имел в виду не для команд, а для информирования о состоянии закаче

для команд конечно лучше текстовый

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от sig_11

Нужен совет

> Хороший пример как сделано - это ISC dhcpd (omshell)

как-нить гляну

еще хороший пример — mplayer, например для наложения поверх фильма анимированного лога задаешь несколько параметров в ком. строке и запускаешь прогу, генерящую лого, а мплеер это лого читает через пайп

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от sig_11

Нужен совет

> не вижу никаких сложностей, возможно кроме некоторых расширений ftp

или это попытка троллинга?

ftp в общем-то простой и обычно достаточно его малого подмножества, а вот полноценно реализоваить протокол dc я подозреваню самому слишком тяжело.

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от www_linux_org_ru

Нужен совет

На самом деле там тоже ничего сложного. У меня был опыт написания небольшого бота на Яве, который скачивал у всех на хабе файл листы и умел шарить файлы (считать TTH хеш для них и составлять файл лист). В принципе там тоже ничего сложного, но у проекта была большая проблема с проектированием (я начинал писать просто для себя, пощупать протокол), потом навалилось дел и я забил. Единственная проблема - у протокола довольно невнятная документация, есть конечно хорошая вики, но там инфа порой написана неполная, приходилось через гугл по мейл-листам и исходникам клиентов шарить. у ADC такой проблемы нету.

sig_11 ()
Ответ на: Нужен совет от devl547

Нужен совет

Просто сказать, если ты не видел его код. А я видел.

sig_11 ()
Ответ на: Нужен совет от sig_11

Нужен совет

> У меня был опыт написания небольшого бота на Яве, который скачивал у всех на хабе файл листы и умел шарить файлы (считать TTH хеш для них и составлять файл лист).

хммм...

тогда бы хорошо написать что-то модульное, чтобы функции можно было вызывать и отдельными прогами с ком. строки, и в составе приложения

я кстати задумывался над тем, как например избежать многократного запуска curl-а при скачивании тучи мелких файлов — и предположил, что необходим ключик ком. строки, при котором curl сидит на stdin-е и каждую прочитанную из него строку парсит как свои новые argc и argv

видимо, этот же принцип можно заюзать при изговтовлении немонолитного гуи-комбайна в юникс-стиле

хотя это синхронный вариант, а в асинхронном надо обернуть curl в сокет с тем же подходом

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от www_linux_org_ru

Нужен совет

и может еще форковаться каждый раз, а то х.з. что там осталось с прошлого запуска

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от sig_11

Нужен совет

> (считать TTH хеш для них и составлять файл лист).

ТТН можно считать и отдельной прогой (она есть), хороший вариант такой проги сидел бы на stdin-е и получал оттуда названия файлов, а выплевывал бы хэши.

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от www_linux_org_ru

Нужен совет

Плохая идея только потому-что есть расширения для dc++ которые используют "ноды" tth дерева (например TTHL, использует конечные "листья" (хеш 1024 байтов) дерева чтобы подтвердить что кусок файла был принят верно). К тому-же хотелось бы реализовать мультипоточное хеширование внутри демона (или отдельным демоном) чтобы можно было контролировать процесс хеширования, и если надо приостановить его. Собственно тут на самом деле ничего абсолютно сложного нету.

sig_11 ()
Ответ на: Нужен совет от sig_11

Нужен совет

я помню она и хэши более мелких блоков могла считать, только наверно 1024 КБ, а не байт

я бы его *обязательно* делал отдельным демоном, чтобы его можно было (ре)найсить, давать io priority, ...

раньше меня достал этот гуевые якобы удобный (но на деле тормозной) dcpp, и от своей реализации удерживал только страх перед сложностью протокола, и вот оказывается он не так уж сложен

но сейчас у меня быстрой локалки в обозримом будущем на долгие промежутки времени не предвитися, так что вряд ли я займусь этим, так что решать тебе

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от sig_11

Нужен совет

> $ cat test.txt | awk '{print(«url = \»«)$1(»\«»)}' | curl -K -

а он наверно сначала *полностью* прочтет конфиг, а *потом* только начнет работать

а надо чтобы в процессе :-)

www_linux_org_ru ★★★★★ ()

Нужен совет

я раньше пробовал что-то похожее, но у меня была та проблема — полное чтение

надо будет свои скрипты переписать...

www_linux_org_ru ★★★★★ ()
Ответ на: Нужен совет от www_linux_org_ru

Нужен совет

Нет, именно 1Кб блоки надо хешировать, потому-что 1024Кб - это 1 Мб что слегка жирно согласись.

sig_11 ()
Ответ на: Нужен совет от provaton

Нужен совет

> можно еще эрланг попрбовать.

+1

isden ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.