pushkin
хех... круто... если есть реальное желание и возможность - супер!
только если серверная/клиентская часть будут сугубо под *nix - ИМХО в массы не пойдёт. Клиентскую часть думаю 99% будут юзать виндовую. Серверная - 50/50. Лично у меня тока винда (2000pro-sp4/2003-server-StandartEdition-rus).

Так как с виндой сервер/клиент?

Есть большое желание не мудрствуя лукаво пользовательское междумордие сделать на жабе (j2se). Т.е. там, где нужна морда - она будет жабовская. Цепляться к тому, чем она управляет, буде то сервер или гейтвей, оно должно по ip для простоты и универсальности. Таким образом мы добиваемся возможности использовать легковесные клиент или гетвей на слабой машине, а рулить ими удалённо.
Клиент - вообще вариант развития гейтвея, если вдуматься (ну или гейтвей - вариант клиента). Так что схема таже. Нужна морда - вот тебе жаба. Не нужна морда - ну и не надо.

Что касается самого клиента и сервера, то знаю людей, обладающих парком слабых машин. Они готовы пустить их в дело. Посему сервер и гейтвей будут созданы максимальны легковескными (под юниксом это демон, под виндой или os/2 или чем ещё - обычное консольное приложение или сервис). В наши дни создать кроссплатформенное приложение типа сервис технически несложно, благо все средства для этого есть. Совместимость между операционками на уровне исходников беру на себя.
Графический же интерфейс реализует java, так что тут соместимость на уровне бинарников - это проверено.

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

Но всё это обсуждаемо. Понятно, что платформы и ОС должны поддерживаться все основные. Но мне сейчас наиболее интересны идеи, фичи, know-how, фишки самой архитектуры. Что мы можем предложить, чего нет у других (окромя возможности менять проект и делать с него форки) ?

И ещё: если есть необходимость делать какие-либо преобразования звука на уровне сигнала (менять тональность, ставить фильтры, эффекты), то мне нужны будут консультации математиков на эту тему.

Немного сумбурно поясню по общей схеме:


Консоль управления <--tcp--> Сервер <--tcp--> Клиент 1
<--tcp--> Клиент 2
<--tcp--> Клиент N
<--tcp--> Гейт 1 <--tcp--> Консоль управления
<--tcp--> Гейт 2 <--tcp--> Консоль управления
<--tcp--> Гейт N <--tcp--> Консоль управления


Само собой, что консоль управления и то, чем она управляет, могут стоять и на одной машине.
Про дублирующую систему (переход на запасной сервер в случае отказа основного): делается легко и непринуждённого.
Про явные минусы eqso, которые я видел: открытие слушаюшего сокета (tcp или udp - уже не помню) на клиентской стороне, что затрудняет работу сервиса с некоторыми провайдерами. Ну и вносит определённые бреши в безопасности, которые ещё нужно уметь устранить. А что, в FRN такая же хрень?

Как видно, клиент мало чем отличается от гейта с консолью :)

Думаю, что в самой архитектуре ничего принципиально нового не предложить, разве что сделать возможность коммуникации сервер-сервер (для создания сети серверов).
Отдельно открыт вопрос с передачей текстового трафика. Нужна возможность или не нужна? А то ведь его можно и телеграфом в эфир, тут проблем никаких :)

ЗЫ: МОжет в отдельную тему уйдём?

Кстати, расскажите ещё в качестве затравки: а чем плох эхолинк?

Ещё в процессе brain storm: если реализовывать концепцию управления через web-browser, то:
1. Должен ли быть web-сервер отдельной софтиной (nginx/apache/whatever) или частью софта (простенький однотредовый веб-сервер под конкретную задачу не требует сложных конечных автоматов и легко пишеться за пару дней и отлаживается за пару недель).
2. Должен ли web-сервер предлагать полный интерфейс управления или только самый коротенький (типа включить/выключить, сменить комнату)?
3. Оно вообще надо? Имхо иногда. Например владельцу гейта Сергею Куликову сообщают, что репа не работает. Он с мобилы или с конторского компа заходит в броузер и пытается делать шаманские движения.

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

эхолинк это то из чего портировали еКуесо. Следовательно наличие тех-же приколов допускается мною.

TheKindWizard
эхолинк это то из чего портировали еКуесо.

Для эхолинка доступны исходные тексты? На каких условиях?
Или имелось ввиду, что екуесо с эхолинка передиралось? :)

Екуесо это именно "порт" для 433мгц безлицензионок. Автор тот-же вроде.

pushkin

ТЗ к разработке системы и ПО.

1) СЕРВЕРНАЯ ЧАСТЬ.
1.1) Сервер запускается СЛУЖБОЙ (а не приложением) и управляется из отдельной консольной программы, либо по HTTP по указанному в настройках программы порту.
1.2) Возможность ограничения удалённого доступа к администрированию (по IP).
1.3) Внешняя база пользователей (и админов) в mySQL (ID, class, Name, pswd, callsign, email, icq, web, phone, birthdate, country, city, comment1, comment2, band, mhz, ctcss, flags, activated, reg_date, reg_ip, last_login_date_time, last_ip, ...). Юзеры по class делятся на админов (класс 1 до 20), юзеров (класс 51-61) и линки (31-39).
1.4) Внешняя база комнат и их настроек в mySQL (rID, name, comment, rules, codec, pswd, max_users, admin_IDs, reg_date, ...)
1.5) Кодеки протокола сервера - обсуждаемо. ;)
1.6) Журналы (.LOG'и) в внешней базе mySQL - системный (работа программы сервера, изменения параметров и кем, ошибки, в mySQL и текстовике!), юзеры (логины, смены комнат, длительные передачи (более 1 минуты), логауты, и т.п.), админы (логины, действия, логауты).
1.7) Доступ на сервер ТОЛЬКО юзеров из муСКУЛ базы (пустые пароли невозможны!). (Фунцкия регистрации юзера в базе - через сайт).
1.8) Блокировка юзера/линка (данные хранятся в муСКУЛе) - mute (он не может передавать ничего в систему!), kick (простое отключение юзера. Он может вернуться сразу же), ban (на время от 0 (permanently) и больше минут. Причину текстом указывает админ).
1.9) Управление линками через сервер, уполномоченными админами (по class) - коммент линка, уровени громкостей микрофона линка, вкл/выкл слуха/передачи линка.
1.10) С сервера, централизованное, настраиваемое управление аудио событиями TX линка (информерами линков). Линки следят за апдэйтами информеров на сервере и их параметрами (интервалы времени/переодичность/график запуска).
1.11) Настраиваемые ответы сервера клиентам/линкам (события) по запросам DTMF. Например клиент (юзер или чел. из эфира через линк) запросил DTMFом инфу о пробках и сервер передал юзеру/линку аудио инфу (WAV или MP3).
1.12) Настраиваемое на сервере блокирование флуда юзером (кратковременные, частые TX в систему).
1.13) Продумать возможность экспорта по TCP порту аудио потока комнаты сервера (stream, типа инет радио, для реализации на сайте(ах) возможности прослушивания комнат НЕ заходя на сервер).
1.14) Отправка подключающимся клиентам важных новостей сервера (сообщения администрации, ну типа - сервисные работы такого то числа в такое то время).
1.15) Встроенная комната TEST с "попугаем".
1.16) Настраиваемые шаблоны мессаджей сервера клиентам по e-mail или онлайн (текстовые шаблоны с простыми макросами).
добавил:
1.17) Функция кросса на другой такой сервер, в выбранную комнату. :)


2) КЛИЕНТСКАЯ ЧАСТЬ.
2.1) Единая программа настраиваемая как клиент или как шлюз (с открытием/закрытием соответсвующего функционала).
2.2) По функционалу все можно скопировать из клиента FRN. Только "подсветку" вещающего юзера/линка ИМХО надо сделать более наглядно. ;)
2.3) Возможность посылки DTMF запросов на сервер и 5-10 изменяемых "любимых" DTMF.
2.4) Удалённое управление линком через простой web интерфейс, с возможностью ограничения доступа по IP.
2.5) При 3-х кратной подряд неудаче коннекта к центральному серверу, автоматом коннектиться к дублирующему.
2.6) Автоматический реконнект линков к центральному серверу в 3 часа ночи. Если линки на резервном и центральный уже в работе - коннектяться к центральному.
2.7) Включаемая возможность автоматической отправки уведомления e-mail'а сервером владельцу линка о отключившемся его линке более 5 минут. Т.е. в найстройках линка "галочка" - Посылать уведомления мылом когда линк "упал". :)
2.8) Так же как в ФРН клиенте - возможность сворачивать в трэй и ПТТ по горячей клавише на клавиатуре.
добавил:
2.9) Выбор звукового устройства для IN и OUT (если в компе несколько звуковух)!
ещё добавил:
2.10) Очень желательно сделать ещё отдельную ТОЛЬКО линковую часть, которая работает как СЛУЖБА! Это для "продвинутых", у кого линки круглосуточно или почти. Удобно если свет отключали и при включении линк сам запуститься! Управление и настройка из консольной проги и из неё же удалённо через инет (если внешний IP есть, даже динамический как у СТРИМа).

Пока вроде бы всё. :)

(!!!) Крайне желательно продумать/сделать возможным мониторинг сервера с сайта (PHP скрипт, запрос списка комнат с коментами и списка юзеров (комент, позывной, откуда) в них).

ЗЫ: Чем могу - помогу. Могу сделать простой интерфейс PHP регистрации (формы) в мускуле с первым этапом проверки на заполненность всех полей корректной инфой. Выбороки из муСКУЛА и т.п. :) Ну и ессесно тестить с баг-репортами. :)

j2se? Тоесть надо-будет ещё и эмуляторы нормальные нарыть/накопать?
Встроенная мастдаевская жв-машина врядли будет нормально работать со звуком. Как пример Lotus Sametime - он нормально работает лишь на "айбиэмовской ЖАВА-ВМ".

Есть конечно и плюсы некоторые. Сможет народ с КПК работать под эмуляторами....

Не проще поступить так как сделано в екуесо и фрн, т.е. "сервер <> множетво клиентов"?, т.е. без отделяемой интерфейсной части?

Да, имхо привязываться к внешней ява/фигава части - обрести гемор с вылавливанием глюков на разных версиях/подверсиях. Объяснять клиентам что и где качать и в какой последовательности ставить икак запускать... а если у них на компе глюк - всё... потерянный клиент, +1 недовольный, +много высказываний "ничего у вас не работает"... в итоге мрачные облака вокруг системы. :(

TheKindWizard

поясню насчёт явы.
консоль управления и клиент на жабе - именно для многоплатформенности. Назовите мне платформу окромя кастратов, где нет j2se?

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

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

Да и потом: протокол обмена известен и прост (имхо xml over http - просто и со вкусом), пишем любую морду к сервису на любимом инструменте.

Вы мне предлагаете опять же упереться в ограничения платформ. А какой мне тулкит брать? wxWindows? - А Вы его пробовали? gtk? - ну можно, но ппц... QT? - вариант, но тоже не лучший.
А писать всё это на visual c/studio и опять огребать грабли и слова "а почему под линюксом нельзя" - да нафига оно такое надо. Придётся тащить сразу несколько проектов: по одному на каждую ОС. А отделив междумордие (интерфейс) от сервисов, мы получаем возможность строить любые интерфейсы минимальными силами.

Насчёт опасений, что жаба плоха для звука. Да ничего подобного:
1. Проекты типа mjsip и куча других работают на j2se превосходно.
2. Жаба она тем и хороша, что у неё есть стандарт. Я никогда не писал на неё звук, но выводить - приходилось. И я скажу, что проблем никаких нет.

salex
Да, имхо привязываться к внешней ява/фигава части - обрести гемор с вылавливанием глюков на разных версиях/подверсиях. Объяснять клиентам что и где качать и в какой последовательности ставить икак запускать... а если у них на компе глюк - всё... потерянный клиент, +1 недовольный, +много высказываний "ничего у вас не работает"... в итоге мрачные облака вокруг системы. :(

Т.е. всё-таки gtk/qt/wx ? Мда.... вот это точно будут костыли, бгг. Ладно, посмотрим, что можно сделать. По тз отпишу чуть позже.

Ну можно и с флэшем ещё поизголяться.... но я ниразу не пробовал что-нибудь серьёзное там делать.... рисовал только как-то.

В любом случае, некоторое время надо на чем-то работать...
Если мыло писать не будем, то.... нет так нет. =)

Я на жаве видал тот-же SameTime - красота....
Если вы уверены, что проблем не будет.... вобщем-то вы программер, вам виднее.

Я скажу так: я на яве за последние 3 года участвовал в 3-х коммерческих проектах (все 3 основал, позднее их подхватили другие люди и коллективы). Всё там абсолютно нормально. Отличная платформа для серьёзных решений.
Единственная проблема у пользователя: 1 (один) раз поставить java runtime, что делается кликом на лицензионном соглашении, скачиванием файла (13 мег где-то) и его запуском. А у многих ява уже стОит.
В винде никакой явы давно уже нет, насколько я помню. Сан выйграла суд и билли запретили воровать чужое.

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

pushkin
даёшЪ экспериментальный образец с минимальным набором функций!
Скелет так сказать! А дальше навешать "мяса". ;)

salex
угу, приду с работы, пообщаемся по твоим предложениям, есть, что обсудить. Не люблю начинать, не прояснив полностью, что именно делаем :) (кстати! мироовой опыт: до 75% проектов не выполняются в срок или умирают на этапе подготовки из-за изменения условий).
За proof-of-concept дело не заржавеет.

Предлагаю подумать, чем народ заманивать будем. Итак, люди попробовали eqso, Люди попробовали FRN. Нам есть, что им сказать? Манагеры, ваше слово?

Ещё пара слов:
Чем хорошо то, что есть сейчас - eqso и frn? Оно легко разворачивается. Само ПО. Поставил и практически больше ничего делать не нужно.

Возможность управлять через броузер - значит должен быть вебсервер. Полноценное управление через броузер - это сложный вебсервер. Сложный вебсервер писать самому - это ппц. Люди на этом собаку съели. Это почти также сложно, как транзакционная машина :) А значит в поставку нужно включать вебсервер? Да ещё с каким-то языком типа php/perl/etc? А какой именно и разрешает ли это лицензия? А если нет - значит администратор сервера должен поставить и настроить его сам. А это усложняет задачу. Сильно. А значит либо:
а. у нас будет ограниченное кол-во серверов и гейтов (по кол-ву людей, имеющих IQ, чтобы поднять и настроить тот же апач на винде или хрюниксе). Плохой вариант.
б. у нас не будет нормального управления через веб, либо будет очень тупенькое, только самое основное и не более того. Потому что вебсервер будет самый тупеький наколенный интегрированный. Превед изобретателям велосипедов.
в. ваш вариант - ??

pushkin
>> Предлагаю подумать, чем народ заманивать будем. Итак, люди попробовали eqso, Люди попробовали FRN. Нам есть, что им сказать? Манагеры, ваше слово?

Главное, что всегда привлекает - рекомендация и указание на стабильность и дополнительный нужный, удобный функционал! ;)

Вебсервер моЧный, с SSI и т.п. не нужен!
Нужно, чтоб слушал по 80му порту и если правильный логин и пароль - давал ОДНУ страничку, на которой ОДНА форма, в которой все САМЫЕ необходимые найстройки для удалённого админства линком! Серверу можно и не делать веб-фейс! Это мона и потом доделать, когда всё основное уже будет отлажено... а может и вообще он серверу не нужен! :)

Потому как ты прально сказал - если кроме самой программы в пакет будет входить вебсервер, пхп/перл, и ещё какая-ньть фигня - проблемм с инсталлом у простого народа будет МОРЕ! Ведь юзвери же как - написано A B C а они назло делают C A B и потом орут - у меня опять ниче не работает! ;))

Нужно, чтоб слушал по 80му порту
Страшно.По 443 тогда уж.

pinguin
не, чёт сглупил, не по 80му (там вебсервенты висят), а скажем по 10001 :)
и никаких 443 ! :)

salex

1) СЕРВЕРНАЯ ЧАСТЬ.
1.1) Сервер запускается СЛУЖБОЙ (а не приложением) и управляется из отдельной консольной программы, либо по HTTP по указанному в настройках программы порту.

Что значит "консольная программа"? Программа, выполняющаяся в консоли (не в графике) ? Если да, то почему так?

1.3) Внешняя база пользователей (и админов) в mySQL

Зачем БД? Вы юзеру предлагаете sql-сервер развернуть с сервером и гейтом? Имхо, не нужно это. Если уж хочеться заморочиться с базой, то есть отличный движок, зовётся Berkeley DB. Маленький, шустрый, не нужно от юзера никаких настроек, поставлять его вместе с прогой.
Моё имхо - все настройки легко делаются в xml-конфигах и не имецца никому моск :)

1.5) Кодеки протокола сервера - обсуждаемо. ;)

Самое время обсудить!
А в качестве протокола предлагаю использовать SIP (rfc 3261).

1.6) Журналы (.LOG'и) в внешней базе mySQL - системный (работа программы сервера, изменения параметров и кем, ошибки, в mySQL и текстовике!), юзеры (логины, смены комнат, длительные передачи (более 1 минуты), логауты, и т.п.), админы (логины, действия, логауты).

Вай опять mysql. В общем, журналы хорошо, но тянуть сюда такую бд, когда есть нормалные читабельные текстовые файлы. А если кому хочеться красивых парсеров и вывовдов статистики в html, предложение журналы вести в бинарном виде (хоть в berkley db), а уж дальше чё хотите то с ними и делайте.
Ну и дублировать в текст. Или тулзу для разбора в комплект класть. Обсуждаемо.

1.11) Настраиваемые ответы сервера клиентам/линкам (события) по запросам DTMF. Например клиент (юзер или чел. из эфира через линк) запросил DTMFом инфу о пробках и сервер передал юзеру/линку аудио инфу (WAV или MP3).

Если честно, я никогда не работал с DTMF. Если кто кинет вменяемой ссылкой на алгоритм выкусывания DTMF-сигналов из raw-аудиопотока - буду весьма благодарен. Кстати, всё уже придумано до нас (не программистам не читать).

1.12) Настраиваемое на сервере блокирование флуда юзером (кратковременные, частые TX в систему).

Отличная идея. Это уже реализовано в каком-то софте? Тему можно развить.

1.14) Отправка подключающимся клиентам важных новостей сервера (сообщения администрации, ну типа - сервисные работы такого то числа в такое то время).

Вообще я уже это кое-кому говорил, повторю и здесь: мне эта затея всё больше напоминает один известный IM, а именно jabber. SIP там кстати тоже поддерживается. Сервер - jabber-сервер любой с поддержкой sip, клиенты - стандартные или почти стандартные. Ляпота! :) Рация к этому привинчивается вместо микрофона и спикера.
Есть специалисты по протоколу XMPP?? Что скажете, други? Кто может взять на себя эту часть вопроса и пообщаться с пиплами из команды разработчиков джабера?

1.17) Функция кросса на другой такой сервер, в выбранную комнату. :)

Ну коммуникация s2s как бы сама-собой напршивается.

По клиенту потом.

по протоколу XMPP работать тяжеловато... по крайней мере именно с жабёром. Уж очень там всё запутано.

По поводу кодеков-компрессии - надо посмотреть на сами кодеки, например на что-нибудь из набора LH, чтобы и скорость потока поменьше, и качество не очень страдало.... в этом вопросе я отстал от жизни.

Кстати там по ссылке тема кодеков затронута краем... в частности речь о G.723.1

TheKindWizard

Из исходных кодов asterix (Open Source PBX and telephony toolkit):
* The G.723.1 code is not included in the Asterisk distribution because
* it is covered with patents, and in spite of statements to the contrary,
* the "technology" is extremely expensive to license.
*
* Copyright (C) 1999, Mark Spencer

Глубже пока не копал. Можно ли про набор LH подробнее?

Ежели одновременно запустить эти проги и гонялку "ралли монте-карло", это и будет авторепа? А если Ил-2?
!абыР

pushkin
>> 1.1 Что значит "консольная программа"? Программа, выполняющаяся в консоли (не в графике) ? Если да, то почему так?

Не... несовсем видимо я правильно выразил мысль. Простая отдельная программулина, в которой указываеш IP и порт сервака, она ломится на него, спрашивает у тебя пароль админа, проверяет и потом СЕРВЕР предоставляет этой проге набор функционала, который по class'у доступен этому админу! О как. :)
Ведь сервер то службой работает и не имеет фэйса. :)
Вообще ИМХО серверной части красивый фэйс не нужен. Просто, черное на сером/белом, красным - важные/критичные мессаги, синим статус "функция работает". :) Красивые кнопочки, рюшечки и т.п. тут не к чему, этож серверная, а не клиентская часть! ;) Меньше рюшечек - больший шанс стабильности. ;)

>> 1.3 Зачем БД? Вы юзеру предлагаете sql-сервер развернуть с сервером и гейтом? Имхо, не нужно это. Если уж хочеться заморочиться с базой, то есть отличный движок, зовётся Berkeley DB. Маленький, шустрый, не нужно от юзера никаких настроек, поставлять его вместе с прогой.
Моё имхо - все настройки легко делаются в xml-конфигах и не имецца никому моск :)

Юзер, который решил заморачиваться с установкой, настройкой и поддержкой СЕРВЕРА (а не линка!) - уже не просто юзер, а юзер взявший на себя некий гемор. "Сам нарвался". :))))))))
Внешняя онлайн база ИМХО для того, что бы можно было оперативно-онлайн связать сервер с сайтом(ами), статистиками, другими онлайн сервисами! К примеру, та же "проектируемая" Уральцем (sp002) единая база LPD/PMR позвных будет в муСКУЛЕ (не у меня). Хранить в бинарной базе это всё, или в текстовиках, или ещё в какой то другой системе = поиметь серьёзный гимор связывая онлайн web хозяйство и сервер (кстати, придумать бы название какое-ньть серверу и системе, чтоб понятнее было о каком сервере речь идёт ;) ).

>> 1.5 А в качестве протокола предлагаю использовать SIP (rfc 3261)

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

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

В принципе мона логи и в простые текстовики класть (автоматом резать на месяца)... но если уж будет муСКУЛЬная база юзеров, то и логи мона туда класть. Согласись, что сортировки, выборки значительно БЫСТРЕЕ и легче будут происходить, чем потом "лопатить" скпритом килограммы текстовиков! ;)

>> 1.11 Если честно, я никогда не работал с DTMF. Если кто кинет вменяемой ссылкой на алгоритм выкусывания DTMF-сигналов из raw-аудиопотока - буду весьма благодарен. Кстати, всё уже придумано до нас (не программистам не читать).

Я не говорю, что давайте придумаем DTMF! :))) Я предлагаю сделать такой функционал ответа сервером конкретному юзеру (только юзеру/линку, а не всем в комнате по его запросу) по декодированным DTMF сигналам. Ну например, запросы типа:
##010 = перечень основных информеров системы (этих) :)
##101 = текущее московское время :)
##911 = вызов администратора, который может быть сейчас в онлайне (отдельная интересная тема - как это реализовать :) )
##211 = пробки на дорогах москвы
##212 = пробки в питере
##213 = крышки в деревне нью-васюки
##*** = вызов службы газа соседу Васе Пупкину. :))))))

ИМХО, с этой функцией можно на потом... подумать над ней хорошенько сначала... и так и сяк... как лучше будет. :)

>> 1.12 Отличная идея. Это уже реализовано в каком-то софте? Тему можно развить.

Ну ни в eQSO ни в FRNе я похожей идеи не нашёл. :)
Но если система будет массовой (комнаты, в которых много линков и юзеров), то хоть на первоначальном (программном, регулируемом) уровне надо блокировать флуд (краткие, частые TX в систему; частый "белый шум" без "несущей"; "пустая несущая" типа забыл PTT отжать и т.п. :) ), тем самым облегчать работу админам/модераторам и соответственно предотвратить раздувание модерского/админского состава по понятной причине - много народу в большом кол-ве комнат, и везде надо порядок поддерживать. :)

>> 1.14 Вообще я уже это кое-кому говорил, повторю и здесь: мне эта затея всё больше напоминает один известный IM, а именно jabber

Ну в чём то похожих систем в инете полно. :)
Про текстовые мессаги - этот "модуль" можно будет использовать в целом ряде пунктов! Например, если для какой то комнаты есть ограничения, или спицифичные правила, или ещё какая то ВАЖНАЯ инфа, то при заходе в комнату - клиенту мессага высвечивается, чтоб не было потом "я не знал об этом!".
Или... неизбежно будут г@внители (они всегда и везде были, есть и будут!). Например, "нарушителя порядка на сервере", чтоб он больше не матерился, не п@носил и т.п. - заМУТили, т.е. он RX-онли, и ему при заходе в каждую комнату об этом пишется мессагой. Вот тут то, в частности, и могут пригодится выборки из логов - сколько "предупреждений" делали ему админы/модеры. :)

-----------------------------------------------------
и ещё добавлю к ТЗ пункт (обсуждаемый)
1.18 Создаваемая админами постоянная комната может быть симплексной или дуплексной! Например для эфиров - симплексные, а для инет-трёпа отдельная, дуплексная комната "КУРИЛКА". :) Юзеры, могут ВРЕМЕННО создавать комнаты (срок жизни комнаты = пока в ней кто то есть), НО только симплексные.

Пора всё это разбивать по частям и думать над каждой отдельно. Очевидно, собирается зародиться что-то комплексное. Позже напишу свои мысли.

Есть такой кодек GSM 6.10 (1-8Kbps) на котором работает ФРН.
LH = Lernout & Haspie (5-16Kbps)

Так-же вот тут есть кое-что: https://www.cs.tcd.ie/Donal.OMahony/omahony-Internet-Telephony-Course-1998.ppt

Сёдня первый раз за почти неделю круглосуточной работы, примерно в 5 утра падал FRN сервак 2007.008 (завис), тот который на Win2000. Так что и на w2k он не живёт стабильно. :( Но значительно дольше чем на wXP / w2003. :)
К слову... eQSO сервер (1.13, PMR446 build) работает без единого падения на w2003, уже ~месяц. 3тьфу. :)

salex
Сёдня первый раз за почти неделю круглосуточной работы,
У меня рекорд 5 дней. =)
Есть кое какие догадки по поводу его зависания, но пока это неподтверждённая информация выкладывать думаю не стоит.
Я восстановил сервак после замутов провайдера с mac-адресом, который само сабой не подходил. В общем взбрело им в голову такую фишку включить...
Ради эксперимента пока не стал запускать eQSO - посмотрим сколько до зависания проживёт, отсчёт пошёл.