Вопросы по RusHub, Технические вопросы

Возник вопрос. Можно как-то указать путь, куда будут создаваться хабом файлы. Я запустил по-простому - в итоге все файлы в папке system32. Не очень удобно.
зы По-простому - это через srvinstw и instsrv

Пока такой возможности нету, однако есть же специальные проги, например, FireDaemon Service Manager, которые позволяют указать откуда запускаться службе. Ведь не обязательно использовать стандартные пути создания служб. Или это так принципиально?

Да нет, не принципиально, но фаердемон бесплатный позволяет только одну службу создать и он уже используется, а крякнутый pro нежелательно использовать. Сервер на работе и там все должно быть тип-топ, на счет вареза ;)
Ну да ладно, я ярлыков в папку отдельную насоздавал и пользуюсь, чтоб не искать файлы.

Че-то несмог изменить предыдущее сообщение, потому оверпост.

А только один порт можно прописать? А как же 1209? У меня половина юзеров его пользует...

Будет-ли поддержка прослушки дополнительных портов? Если уже есть то как установить? Например у меня хаб стоит на 411 и 4111 портах...

Внимательно читаем тему самого хаба и видим:

Многоядерность данный хаб задействует? И выдержит онлайн 15тыс. пользователей? А то Верли мрёт под фряхой...=(

как ты представляешь многопоточный хаб - для начала расскажи эту концепцию. Ведь хабы работают с одним потогом данных. Куда и зачем пихать второй поток.
Ну и верли и фряха. Ну ты понел. Немного не то это. Он же на линукс пишется.

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

ИМХО, заблуждаешься. Данные ктоме того что в потоке одном, они еще и по очереди идут. то есть юзер выполнил команду - и он встала в очередь. Очередь дошла - хаб выполнил команды и вставил её в очередь на отправку. И причем очереди зависят друг от друга. То есть в каком порядке идут запросы, от том же порядке идут и ответы хаба. То есть иначе всеравно надо вводить какие-то блокировки, чтобы не нарушать последовательность. И зачем тогда городить велосипед?

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

Eсли скрипт удалить из папки, то он не удаляется из списка скриптов, даже после перезапуска всех скриптов. Это так и должно быть? Пробовал даже тупо из Scripts.xml удалить... Глухо, они опять там появляются.
Надо обязательно хаб перезапускать или есть способ, который я не учел?

Спасибо. Исправлю.

Я не прогер, может это и не возможно... разделить по потокам:
один - юзерлист
второй - поисковые запросы ... для активов
третий - поисковые запросты для пассивов
четвёртый - главный чат и лички
пятый - сжатие трафика zlib, т.е. всего, что сделают вышеуказанные потоки?

Меня даже интересует в данном случае не это, а что впринципе делать, когда хаб достигает критической точки?

Щас я вижу DC - как систему, с явным тупиком. В хаблисте сейчас на первых трёх хабах отключили выдачу тегов, и ттш поиск, т.к. они уже достигли этого тупика. На авангарде поставили ограничение ттш и обычного поиска...
Это всё щас дало им запас, но больше 15 тыс они всеравно не потянут...Проект должен развиваться, но развитие ограничивает техническая реализация.

Есть ли способ как-то распределить нагрузку, кроме линковки? Она всётаки согласитесь, не очень удачный выход...

Может быть можно как-то запустить допустим 10 хабов и один основной, играющий роль роутера?
Чтобы оснновной только получал, распределял и перенаправлял трафик, а 10 других обрабатывали всё, что поступает от основного?

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

lightuserdata - что за зверь такой?

Это указатель на сишный объект. В скриптах такой тип данных имеет только UID.

Тогда в чем отличие от типа userdata? Ведь везде упоминание идет только о нем, приставки ligt- нету...

Для lua нет разницы, можете называть просто userdata (даже неверное так и следует делать чтобы не сбивать с толку).
Разница есть только для си.

А никто не хочет ответить nail, а то как-то игнорировать человека нехорошо

На больших хабах вполне естественно что всё упирается в производительность системы.

При использовании стека протоколов TCP/IP пользователь идентифицируется сервером по своему ip-адресу, порту на клиентской машине и ip-адресу с портом на серверной машине. Обычно, на серверной машине выделяется по одному порту на каждого из клиентов в текущий момент, следовательно работать с ними можно пользуясь номерами портов и используемым ip-адресом. Вся эта информация скрывается внутри сокетов, которыми можно оперировать как обычными файлами.

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

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

Остается действовать в пределах одного процесса и организовывать цикл обработки сообщений от сетевого окружения операционной системы. Чаще всего используются системные вызовы poll() или select().

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

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

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