singlepost

Файлообменник и менеджер закачек << На главную или назад  

Есть желание написать софт, выполняющий данные функции:
1. Файлообменник по принципу DC (свои протоколы + возможно поддержка протоколов других обменников (если найдем описание))
2. Мэнеджер закачек (FTP, HTTP, SMB)
3. Поиск по ресурсам SMB

Хотелось бы услышать ваши предложения, пожелания и мысли.
Возможно сотруднечество с дизайнером.

83 ответов в теме “Файлообменник и менеджер закачек”

  1. 35
    Андрей Куликов ответил:

    Ну я регулярно имею такое счастье. Скажем так – бизнес логику вобще можно писать никак не зависящую от системы. А вот аппаратно/платформенно зависимоые вещи, реализованные сторонними библиотеками – это да, тут так просто не портируешь. Но есть одно но. Во первых это уже не минус плюсов как таковых – это минус разношорстности API и стандартов и библиотек. Сами плюсы абслолютно переносимый язык.
    Ну и во вторых, как раз для C++ хороших либ, фрэймворков реализующих подобные платформенно зависимые части будь то многопоточность, сетевое программировние (кстати сокеты не самый удачный пример, все они драты с беркли сокетов и API там как раз почти идентично) и т.п. и предостовляющее единый интерфейс. Так что обычно как раз проблем с этим нету.

  2. 34
    Сергей Шакшин ответил:

    Андрей. отнюдь не не подумав сказано.
    я имел счастье писать софт на плюсах под линукс и портирвоать егопотом под виндовс. даже учитывая что подлинуксом это gcc а в винде mingw. взять хоя бы разницу в апи сокетов. и это лишь один из подводных камней. а хочестя написать код и быть уверенным что он заведется в винде так же хорошо.

  3. 33
    Жека Кирпичев ответил:

    Да, кроме обмена ничего нет. У процессов вообще нет общей памяти; у них даже garbage collector у каждого свой.

    Насчет отладки могу сказать вот что:
    - А как отлаживать апач с 1000 коннекшнами?
    - Отлаживать в эрланге, как и в других функциональных языках, очень просто – именно потому, что кроме обмена ничего нет, и один процесс не может ничего испортить другому – нет никаких дедлоков, race condition'ов, несинхронизированного доступа; нет даже изменяемых переменных. Поэтому резко возрастает модульность программы и возможность отлаживать ее по частям, не боясь, что в комбинации части не заработают или что упустишь какую-то неявную зависимость.
    - Отладчик у эрланга есть, вполне полноценный
    - Долгоживущих процессов, со сложной логикой – обычно мало, и Ericsson рекомендует подробно документировать такие процессы – какие сообщения они умеют принимать и какие сообщения отсылают в ответ.
    Короткоживущие процессы обычно делают что-то очень простое, и – во-первых – не так уж просто написать такой процесс с ошибкой – и во-вторых, можно спокойно отладить такой процесс отдельно, потом отладить программу на 2-3 таких процессах и быть увереным, что на 10000 она будет работать так же.

    Скорее возникает вопрос – если тормозит, то какой кусок программы в этом виноват – вычисления, затраты на управление задачами, ввод-вывод? У эрланга есть несколько профайлеров для всех таких целей.

  4. 32
    Дмитрий Щёголев ответил:

    Ну хорошо.вы меня убедили. Но помоему софтина с 1000 процессами это уж слишком жестоко. Как это все отлаживать? И я так понимаю, что кроме обмена сообщениями больше у потоков ничего нет.

  5. 31
    Жека Кирпичев ответил:

    Сергей, документация на сайте //www.erlang.org очень подробная и хорошая – //www.erlang.org/doc/ и //www.erlang.org/doc.html

    Дмитрий, да, нити в эрланге "зеленые" – это очень часто применяется в языках с виртуальными машинами. Именно поэтому они настолько, чем нити ОС. Смотри: //shootout.alioth.debian.org/debian/benchmark.p... – эрланг рвет си в 20 раз; на втором месте хаскелл, у которого тоже "зеленые" нити.
    Сиквел написан на си потому, что там есть очень сложный низкоуровневый и вычислительный код (кстати, интересно, что нити и планировщик задач у MSSQL тоже "свои").
    То, что куча вещей написана на си, еще не значит, что их _лучше_ писать на си.

    Смотри: //www.sics.se/~joe/apachevsyaws.html – апач против YaWS, написанного на эрланге. Апач дохнет на 4000 соединений в секунду, эрланг продолжает жить и при 80000. При этом у эрланга сохраняется скорость выдачи.

    Эрланг разрабатывался специально для написания soft real-time распределенного и устойчивого к ошибкам серверного софта с uptime ~99.999% – в основном для этого он успешно и применяется в больших масштабах.
    Пример – ejabberd; классический пример – маршрутизатор у Ericsson (ради которого они эрланг и придумали) – 850 тыс. строк на эрланге + 1млн на С++ (конечно, в программе такого масштаба есть и части, для которых эрланг использовать не стоит – что-то вычислительное или низкоуровневое); другие примеры тут: //www.erlang.org/faq/faq.html#AEN50 ; вообще если погуглить что-то вроде "we use erlang", найдется множество людей, которые используют его; и почти все – для серверов.

  6. 30
    Андрей Куликов ответил:

    Сергей RiGiD Шакшин
    >> и на плюсах кроссплатформенный код не сделаешь без заморочек
    Ну это конечно не подумав сказанно. ))

    Дмитрий
    Это просто традиция писать системный, сетевой, опенсорсный софт на C. Плюс функциональные языки до сих пор еще слабо расспространены и не так много серьезных спецов в них по сравнению со C.

  7. 29
    Андрей Куликов ответил:

    Вот кстати статейка есть о причинах их нерасспространенности.
    Довольно старая, но с тех пор не так много изминилось в лучшую сторону.
    //www.softcraft.ru/paradigm/fp/whynotfp.shtml

  8. 28
    Сергей Шакшин ответил:

    Жека, а етстьли хорошая документация по ерлангу? желательно на русском, но на крайний случай можно и на аглицком. ПОявилось желание поближе с ним познакомиться.

  9. 27
    Дмитрий Щёголев ответил:

    ну ну. а некоторые еще и под Blitz3D игры лабают.Не люблю я всякие приблуды. И вот еще, я так понимаю многопоточность выполнена переключением выполняемых участков кода в виртуальной машине(сейчас посчитали чтото, через квант времени переслали данные,потом снова посчитали ..ит.д.) .Т.е. по большому счету происходит эмуляция многопоточности, потому что использовать средства самой ос для создания потоков, в рамках которых происходит исполнение инструкций ВМ это просто самоубийство, т.к. выигрыша никакого.Или я не прав? Ксати, ка вы думаете на чем написаны всякие Апачи, Сиквелы, ftp-серверы и прочий серверный софт? Я думаю что все таки на C

  10. 26
    Жека Кирпичев ответил:

    Дмитрий, насчет "делать сложно" – как думаешь, сколько строк у тебя бы заняла, к примеру, реализация IRC-сервера и клиента с простым GUI и поддержкой "комнат" на С++? Сколько времени у тебя заняла бы отладка многопоточности – дедлоков, race condition'ов – всего, чего в эрланге фактически не бывает вообще? Как думаешь, сколько времени бы у меня заняло полностью разобраться, как твоя программа работает и, скажем, добавить к ней новую фичу?
    p.s. Это просто вопросы, а не наезды :)

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

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

  11. 25
    Андрей Куликов ответил:

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

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

  12. 24
    Сергей Шакшин ответил:

    отдельный процесс – штука тяжелая. когда их 20 – нормально,а когда измеряестя сотнями….. у нас socks на шлюзе по такому принципу работал… стало загибаться. перевели на однопроцессовую схему.
    и на плюсах кроссплатформенный код не сделаешь без заморочек. в винде есь форк? насколько знаю нету

  13. 23
    Дмитрий Щёголев ответил:

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

  14. 22
    Сергей Шакшин ответил:

    А я читал не твою статью, я читал какуюто переводную вики по ерлангу.
    а вообще наверно стоит поглубже вчитаться. Сейчас вспомнил чтокорпоративный джаббер у меня на ejabberd работает, а он на том самом ерланге написанный. И даже исходник приходилось руками патчить немного. вроде тогда справился :)

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

  15. 21
    Жека Кирпичев ответил:

    Да, за синтаксис эрланг критикуют, но количество скобок по-моему не превышает допустимого, с лиспом не сравнить. Где там много скобок? Какие ты имеешь в виду скобки – {} или () ? В каких ситуациях их становится много?

    Насчет "не понял как на нем писать" – поясни. Я в презентации не писал, как запускать интерпретатор и т.п., но это можно найти в инете без проблем.

    Гуи на эрланге особенно не пишут, хотя там и есть привязки к некоторым библиотекам.

  16. 20
    Сергей Шакшин ответил:

    как второй разработчик в топиковой команде,скажу свои соображения:
    читал доки по ерлангу, питону и иже с ними.
    1. ерланг не понравился тем что блин выглядит как лисп -скобки-скобки-скобки… пугает, я читал конечно поверхностно, но так и не понял как на нем писать, особенно применительно к гуям. но очень впечатили возможности многопоточности… ну просто очень.
    2. питон в принципе ничего так.понравился, почитаю поподробней.

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

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

  17. 19
    Илья Королев ответил:

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

  18. 18
    Жека Кирпичев ответил:

    Владимир, напиши плз потом свои впечатления от Эрланга – хотя бы начальные.

  19. 17
    Владимир Шакшин ответил:

    Ок. Сэнкс

  20. 16
    Жека Кирпичев ответил:

    Подробностей его лицензии не знаю, но на 100% знаю, что для некоммерческого использования она бесплатна (не знаю на счет коммерческого, похоже что тоже); а сама платформа, компилятор и т.п. – open-source. //www.erlang.org .

  21. 15
    Жека Кирпичев ответил:

    Компилятор в нативный код – HIPE (погугли, забыл ссылку)

  22. 14
    Владимир Шакшин ответил:

    Обязательно посмотрю что это за эрланг. У него существуют фриварные компиляторы?

  23. 13
    Жека Кирпичев ответил:

    Павел, по-моему у эрланга чрезвычайно пологая кривая обучения. Вот, буквально, можно полчаса почитать туториалы и начать писать сетевое приложение. Почесать репу еще часик и начать писать распределенное приложение.
    Синтаксис предельно прост, никаких математических наворотов, как в Хаскелле, нету. Библиотеки – мощнейшие и содержат почти все что может понадобиться – от сбалансированных деревьев и работы с файлами и сокетами, до реализаций ssh, распределенных блокировок, реляционной БД и смены кода на лету.
    Для больших задач я его пока не применял – просто под руку не попадались такие задачи – а маленькие "учебные" задачки я на нем писал вообще безо всяких проблем; сейчас я перед тем как писать что-то параллельное на джаве, сначала пишу на эрланге "псевдокод" и потом переношу на джаву. Он действительно очень и очень простой, и программы получаются очень простые и понятные, и полностью соответствующие сути задачи.

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

  24. 12
    Павел Вязовой ответил:

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

    Вова, я так понял ты говориш про фрипаскаль. Аналогов делфи больше нету. да и не аналог это а какашка. =) Уж лучше QT с егошными приплюснутыми сями. Ну не совсем какашка, но ничего замечательного в этом языке нету, он исключительно для делфи-фанов благодаря аналогу VCL (и частичной совместимости с VCL) и синтаксису object pascal

    Я бы поучаствовал, темболее впринципе отдельные утилиты не обязательно писать на одном языке. Для разработки морды я бы таки выбрал QT, возможно у фрипаскаля есть привязки к QT, хотя мой выбор python с pyqt =)QT штука кроссплатформенная, мощная. Реализует библиотеки для работы с сетью, локализацией, виджеты для разработки интерфейса, но основной плюс – подробная документация и туториал на русском. Туториал настолько хорошо что после пошагового просмотра егошных экземплов впринципе учиться больше и ненадо. Надо будет обсудить, с Ригитом я тоже поболтаю =)

  25. 11
    Павел Вязовой ответил:

    Да, и дай ему (Сереге) линк на этот топик, чтобы он подключился к обсуждению, пока оно идет здесь.

  26. 10
    Владимир Шакшин ответил:

    Благодарю. Обязательно прочитаю.

  27. 9
    Жека Кирпичев ответил:

    Эрланг идеален при написании сетевых и многопоточных приложений – как клиентских, так и серверных. Хотя специально заточен он, конечно, под серверные.

    Владимир, предлагаю почитать про него тут //spbhug.folding-maps.org/wiki/Erlang?action=At... – мой вчерашний доклад на SPb Haskell User Group #4 :)

  28. 8
    Владимир Шакшин ответил:

    To Павел Вязовой
    Полностью согласен насчет того что надо разделять на несколько приложениий с общим интерфейсом. Более того Ве остальное будет сделало ввиде плагинов, что обеспечит довольно простую расширяемость продукта.
    Писать планируется на каком-то бесплатном аналоге делфи, кооторый имеет компиляторы как минимум под винду и линукс. Более подробно об этом может написать наш общий знакомый RiGiD =)

  29. 7
    Павел Вязовой ответил:

    Это должны делать отдельные приложения IMHO, причем согласно святому Unix-way они должны быть консольные, а графический интерфейс к ним может быть один – тогда получится то что тебе надо и то что мне надо, хотя мне ничего ненадо – все есть.

    Чем это Erlang идеален при написании клиентских сервисов? Объясните пожалуйста.

    Владимир Владимирович, вопрос: если планируется кроссплатформенное приложение, то какие средства, обеспечивающие кроссплатформенность будут использоваться? Например если забыть про консольность то можно написать все целиком на QT4, темболее что библиотека простая, ооочень мощная и хорошо документирована даже на русском языке – встроенный учебник. Правда писать на c++ не улыбается, предпочитаю high-level языки вроде haskell, здесь бы вполне подошёл pyqt4 и python.

  30. 6
    Владимир Шакшин ответил:

    to Дмитрий Loriandr Щёголев
    Чем заниматься буду – еще не знаю, ибо студент
    просто пока есть время хочется попробовать поработать в различных направлениях. Плюс получить опыт работы в комманде. Опыт – штука безценная. А гемор – есть в любом деле =)

  31. 5
    Жека Кирпичев ответил:

    Предложение №1 – использовать язык Erlang. Он для таких задач идеален, если не считать GUI – но это не большая проблема.

  32. 4
    Дмитрий Щёголев ответил:

    нах надо) если конечно не будешь потом заниматься этим за деньги, то лучше не начинать. гемора слишком много.

  33. 3
    Владимир Шакшин ответил:

    =) неа. Это делается в первую очередь с целью получения опыта написания таких прог. Никогда раньше не писал таких вещей – решил попробовать.

  34. 2
    DELETED DELETED ответил:

    действительно)) Не проще ли просто создать свой хаб? Раздать знакомым программу-клиент и наслаждаться жизнью?

  35. 1
    Юрий Лунёв ответил:

    велосипед. Очень велосипед.

Клуб программистов работает уже ой-ой-ой сколько, а если поточнее, то с 2007 года.