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

OpenFire - на java

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

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

slackware.

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

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

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

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

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

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

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

java

Ну ты понел.

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

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

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

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

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

>>java

Ну ты понел.

Чтобы не висло нужна мощная машинка

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

Тролль ты, а не программист.

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

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

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

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

Не получится насадить банальное барство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://xmpp.org/extensions/xep-0009.html

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

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

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

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

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

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

Хм, а что это за контора в Барнауле такой сервер хочет? :)

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

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

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

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

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

ну так пиши на C#/Mono, в чем проблема-то?

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

Linux :(

:(

Язабан.

Такие вопросы (вне зависимости от ОС) может задать или тупой ламер или тролль. Выбирай.

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

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

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

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

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

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

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

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

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

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

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

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

4.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

см. рис. 1

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

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

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

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

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