LINUX.ORG.RU

Написание серверного приложения под Linux


0

0

Доброе время суток! Я - программист под Windows, но недавно мне поставили задачу написать программу-агент, серверная часть которой должна работать под управлением Linux :( В линухе я, понятное дело, не шарю. То есть шарю чуть-чуть на уровне пользователя. Итак, подскажите, пожалуйста кто чем может. Работа агента напоминает технологию Jabber, мне надо чтобы:

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

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

А теперь собственно вопросы: 1) Можно ли написать шустрое серверное приложение на java, qt или надо обязательно на C++ ? 2) Какова вообще архитектура подобных приложений? Каждый клиент через сокет соединяется с сервером и все время поддерживает соединение? А сервер не сдохнет от нескольких тысяч открытых сокетов? Для каждого клиента походу на сервере должен создаваться собственный поток(или как там под линухом это называется) для прослушки каждого сокета. А сервер не ляжет от тысяч потоков? 3) Может быть можно взять уже готовое решение, какой-нибудь jabber-сервер и немного перепилить его руками? Подскажите какие-нибудь исходники jabber-серверов. 4) Ну и, конечно же, вопрос-боян. Какой дистрибутив Linux лучше всего позволит сосредоточится на разработке? Именно на разработке а не на настройке этого дистрибутива. Есть mandriva, open suse, kubuntu, серверная версия ubuntu, slackware.

Заранее всем спасибо!

> Подскажите какие-нибудь исходники jabber-серверов

OpenFire - на java

Какой дистрибутив Linux лучше всего позволит сосредоточится на разработке

Если только для работы - любой, ставящийся из пакетов: debian, OpenSuse, Mandriva, Ubuntu

slackware.

Если времени на потрахаться нет - не трожь. Возьмёшь, когда постигнешь ДАО.

Остальные вопросы к Линукс отношения не имеют. Как и вообще к любой из осей.

r_asian ★☆☆
()

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

Ололо Ильхам пишет квип для линупса?

Sphinx ★★☆☆
()

Можешь попробовать на boost::asio написать, в этом случае никто не мешает кодить в вижуалстудии под виндой, а потом просто собрать и потестить на линуксе.

gizzka ★★
()

>Можно ли написать шустрое серверное приложение на java

шустрое серверное приложение


java


Ну ты понел.

qt или надо обязательно на C++ ?


Вообще по дефолту с кутэ работают чрез плюсы.

Да, для каждого коннекта свой поток, в котором обработка. Чтобы не висло нужна мощная машинка. Из дистрибьутивов бери убунту или более стабильный дебиан, на котором она и основана. Про слаку забудь, ты с ней долбаться будешь месяц поначалу, чтобы настроить, особенно если полный ноль в линуксах.

Zhbert ★★★★★
()

> Какова вообще архитектура подобных приложений? Каждый клиент через сокет соединяется с сервером и все время поддерживает соединение? А сервер не сдохнет от нескольких тысяч открытых сокетов? Для каждого клиента походу на сервере должен создаваться собственный поток(или как там под линухом это называется) для прослушки каждого сокета. А сервер не ляжет от тысяч потоков?

hint: Cоединения не обязательно обрабатывать одновременно.

anonymous
()
Ответ на: комментарий от anonymous

>Да Вы просто шикарнейшее ламо, сударь!

Имелось ввиду, что если он воззьмет третий пенек с 333Мгц и 64 метрами оперативы, напишет на яве и приконектит к этому всему пару тыщ юзеров, то вомпутер выгорит нафиг.

Zhbert ★★★★★
()

Мне вот интересно, чем не подходит джаббер?

Можно взять сервер, немного его изменить под собственные нужды, так же поступить с любым клиентом (например psi). Или такой вариант не катит?

irq
()

Тут Линукс - дело десятое. Ты под вендой-то сможешь такое написать?

mv ★★★★★
()

> Подскажите какие-нибудь исходники jabber-серверов.

ejabberd. под нагрузкой не сдохнет ибо ерланг. дистр - дебиан

SevikL ★★★★★
()

>А сервер не сдохнет от нескольких тысяч открытых сокетов? Для каждого клиента походу на сервере должен создаваться собственный поток(или как там под линухом это называется) для прослушки каждого сокета. А сервер не ляжет от тысяч потоков?

man epoll, в девичестве man select. А лучше почитать Стивенса (Ричард Стивенс, Стивен Раго «UNIX. Профессиональное программирование». ) Книга толстая и, может быть, излишне обстоятельно написанная, но пользительная весьма.

А дистрибутивы предлагаю перенумеровать и бросить кубик. Что выпадет, то и поставить. Всё равно на чём шишки набивать.

lodin ★★★★
()
Ответ на: комментарий от Zhbert

>> Да Вы просто шикарнейшее ламо, сударь!

Имелось ввиду, что если он воззьмет третий пенек с 333Мгц и 64 метрами оперативы, напишет на яве и приконектит к этому всему пару тыщ юзеров, то вомпутер выгорит нафиг.


Почитай про событийную модель и C10K problem.
Отмазаться не получилось )

shelA
()

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

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

Можно посмотреть сравнение веб сервера на erlang(Yaws) и Apache

http://www.sics.se/~joe/apachevsyaws.html

Как видно yaws держит для 80 000 открытых соединений.

Еще интересный обзор: http://lionet.livejournal.com/42016.html

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

recon88
()
Ответ на: комментарий от anonymous

Узнал что на java есть XMPP-сервера, например, OpenFire. И ничего. Я не ламо, просто никогда не занимался подобными вещами.

mbinger
() автор топика
Ответ на: комментарий от sdio

Попрошу соблюдать хотябы элементарное приличие

Меня на работу принимали как специалиста по .NET/MSSQL, про линухи и всякие там демоны-сокеты я имею лишь отдаленное понятие.

mbinger
() автор топика
Ответ на: комментарий от Sphinx

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

mbinger
() автор топика
Ответ на: комментарий от mv

Под виндой думаю что да. В студенчестве писал подобные работы с использованием как .NET так и WinAPI. Но одно дело лаба, а другое дело - коммерческое приложение, которое просто не имеет права на зависане и тормоза.

mbinger
() автор топика
Ответ на: комментарий от mbinger

Изучи лучше Erlang, допили ejabberd под свои нужды, можешь и под виндой. Erlang лёгкий, изучается быстро. Развернуть под линуксом проблем потом не будет.

mv ★★★★★
()
Ответ на: комментарий от Zhbert

Не пенек, какая-то интеловская многоведерная шайтан-машина. Не соврать, вроде бы 2 проца по 4 ядра. Решил писать на java. А там ... будет тормозить - буду думать. Посмотрел исходники jabber-серверов на java. Мдаа, черт ногу сломит, проще самому написать. К сожалению, на java я практически ничего раньше не писал :( За дельные советы спасибо. Ну а тролли, которые пишут «ламо» есть везде, никуда от них не денешься.

mbinger
() автор топика
Ответ на: комментарий от mbinger

Правильный выбор. Ты главное не слушай тех троллей, кто херланг советует, потом обплюешься, если свяжешься с этим кошмаром.

anonymous
()
Ответ на: комментарий от mbinger

> проще самому написать. К сожалению, на java я практически ничего раньше не писал

Сразу скажите название «программного продукта» чтобы я ненароком не связался с этим.

anonymous
()
Ответ на: комментарий от mv

> Нафиг самому писать, если уже написано, причём, неплохо?

Вот именно, что написано. На Java. Неплохо. А еще написано на херланге, и очень плохо написано. Выбор, как говорится, очевиден.

anonymous
()
Ответ на: комментарий от mv

>Изучи лучше Erlang, допили ejabberd под свои нужды, можешь и под виндой. Erlang лёгкий, изучается быстро. Развернуть под линуксом проблем потом не будет.

Да erlang хорош,будет правда в начале немножко сложно к нему привыкнуть.
Могу также посоветовать Perlовый фреймворк AnyEvent ,для него есть готовые XMPP модули.

pinachet ★★★★★
()

> серверная часть которой должна работать под управлением Linux :(

Linux :(

:(

Язабан.

anonymous
()
Ответ на: комментарий от anonymous

> Да, для каждого коннекта свой поток, в котором обработка.

Это адски идиотский подход.

а вот и специалисты подтянулись :) обосновать сможешь?

shty ★★★★★
()
Ответ на: комментарий от shty

>а вот и специалисты подтянулись :) обосновать сможешь?

Это что за дождь прокапал, раз сразу столько идиотов повылазило?

anonymous
()
Ответ на: комментарий от anonymous

>а вот и специалисты подтянулись :) обосновать сможешь?

Это что за дождь прокапал, раз сразу столько идиотов повылазило?

простите, в гриме не узнаю, вы тот самый анон или вже другой?

shty ★★★★★
()
Ответ на: комментарий от mv

>Хм, а что это за контора в Барнауле такой сервер хочет? :) К сожалению, это коммерческая тайна :(

mbinger
() автор топика
Ответ на: комментарий от anonymous

А как еще сделать-то? 1) Серверный сокет принимает соединение - для нового входящего соединения создается новый сокет 2) Через новый сокет сервер тем или иным образом обменивается хандшейками с клиентом и встает на прием данных из сокета, ожидает команды. 3) Все реализации синхронного чтения из сокетов, которые я когда-либо видел, вызывают зависание выполняемого потока до полного прочтения информации из сокета. Все реализации асинхронного чтения так или иначе создают новый поток.

Как же сделать «не по-идиотски» все это в одном потоке?

mbinger
() автор топика
Ответ на: комментарий от mbinger

Все реализации асинхронного чтения так или иначе создают новый поток.

4.2

Как же сделать «не по-идиотски» все это в одном потоке?

Кури маны по select/poll/epoll и конкретные примеры из библиотек boost::asio и/или libevent

Reset ★★★★★
()
Ответ на: комментарий от anonymous

>Сразу скажите название «программного продукта» чтобы я ненароком не связался с этим.

Какая разница на чем писать-то? Главное понимать основные принципы. Тут главная задача, я считаю, следить чтобы межпотоковое взаимодействие не вызвало «клинч» и зависание. Если понимаешь принцип написания многопоточного приложения то какая разница на чем его реализовывать? Я вот как раз не доверяю программным продуктам в основе которых разработчики используют сомнительные сторонние библиотеки, не понимая принципов их работы. Да, я согласен, что сложную систему иначе не написать. Но поставленная задача к таким системам не относится.

mbinger
() автор топика
Ответ на: комментарий от mbinger

Но поставленная задача к таким системам не относится.

Если сервер с тысячами коннекшенов для тебя к сложными системам не относится, то что ты тут нам голову морочишь? А что для тебя есть «сомнительные библиотеки»? boost::asio, libevent? Или, может быть, Эрланг? ;)

mv ★★★★★
()

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

ТС, я бы не придумывал велосипед. А взял какой-нибудь комет-сервер (nginx+http_push например), который специально разрабатывался знающими людьми имено для твоих целей (множество одновременных активных соединений). В итоге не надо придумывать транспортный протокол, прототип сервера пишется буквально за полчаса и клиент не должен погружаться в дебри TCP. Единственный недостаток — не получиться обучиться системному программированию под Linux.

anonymous
()
Ответ на: комментарий от shty

> а вот и специалисты подтянулись :) обосновать сможешь?

Смогу, смогу. Легковесные потоки на практике себя намного лучше показывают, а еще лучше - один поток с poll-ом + очередь сообщений + N потоков обработчиков, где N = числу CPU.

anonymous
()
Ответ на: комментарий от mbinger

> Если понимаешь принцип написания многопоточного приложения то какая разница на чем его реализовывать?

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

anonymous
()
Ответ на: комментарий от mbinger

> Как же сделать «не по-идиотски» все это в одном потоке?

На nginx посмотри, да.

anonymous
()
Ответ на: комментарий от shty

> а вот и специалисты подтянулись

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

А как признаешься - иди читать сырцы nginx.

anonymous
()
Ответ на: комментарий от mbinger

Все реализации асинхронного чтения так или иначе создают новый поток.

используй пул рабочих потоков, если решишь таки смастерить свой велосипед

dave ★★★★★
()
Ответ на: комментарий от anonymous

> а вот и специалисты подтянулись :) обосновать сможешь?

Смогу, смогу. Легковесные потоки на практике себя намного лучше показывают,

хмык, смотрим оригинал

Да, для каждого коннекта свой поток, в котором обработка.

ну и где тут про толщину потоков говорится?

а еще лучше - один поток с poll-ом + очередь сообщений + N потоков обработчиков, где N = числу CPU.

ога, какой Вы смелый :) и вот поток встаёт колом или хватает SIG_SEGV и вываливается и что будут делать могучие лоровские оналитеги в таком разе?

shty ★★★★★
()
Ответ на: комментарий от anonymous

Повторяю для тупых - читай nginx, много думай.

читай апачдев, думай внимательно и лучше головой

до кучи, рекомендую просветиться что такое фронт-энд и бэк-энд

и да, чисто по-человечески, рекомендую не изображать из себя агрессивное быдло, а общаться нормально (мне то пофиг, а вот другим участникам дискуссии будет не в пример приятнее)

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