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



Последнее исправление: CYB3R (всего исправлений: 1)

> Одновременно хотелось бы овладеть ещё одним языком, из кандидатов: 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
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.