Цепочка тестов — это интересно. На сколько я представляю, подобная цепочка генерирует всевозможные варианты развития событий/сочатений и результат должен быть в пределах определенных коэффициентов и/или это значение должно быть в пределах определенной дисперсии? В случае отклонения результата от общих/средних коэффициентов в несколько раз/порядков обнаруживается «имба» и уже ручной разбор данной ситуации (пенальти/блокировка сочетания и/или игровой ситуации). Конкретика игры определяет игровые параметры в формуле расчета, относящиеся к характеристикам данного предмета. Все я представил верно? Или складывается логика несколько иначе? В любом случае, я думаю это тоже крайне интересная тема в рамках отдельной статьи -).
Например, как рассчитывается урон от палки, которая имеет характеристики X, достается за потраченное время Y?
Как рассчитывается адекватная стоимость чайника, нагревающего объем воды X за время Y, имеющего возможность улучшить водонагревательный элемент до коэффициента Z? Как рассчитать стоимость и «сложность добычи» спирали с заданными характеристиками? Как рассчитать стоимость водонагревательного чана на 300 литров, который (в игре) своим присутствием не сделает чайники ненужными?
Из того, что я слышал в общих чертах на примере mmorpg: стоимость новой палки X рассчитывается исходя из времени (-необходимого для достижения палки похуже; — необходимого игроку для прокачки умения, которое эта палка игнорирует).
Спасибо за статью. Однако, меня все время интересовало как просчитывается разная игровая механика. Вы очень хорошо описали схему работы и запуска (всех?) игр. Могли бы остановиться в подобном формате про механику? Слышал про целые команды математиков, ежедневно просчитывающих всевозможные вариации.
Точный предел я не помню, каюсь. Как и графиков на данный момент, не сохранилось.
Методика тестирования была следующая: новый сервер вещания был развернут в другом ДЦ (латест стэйбл убунта, icecast2 из пакетов). В конфигурации было установлено ограничение в миллион клиентов. Включили все потоки (на тот момент их было 56). Обновили ДНС-записи на новый сервер. Пошла нагрузка, мониторили онлайн плагином icecast2 к munin. Был достигнут суммарный онлайн в N-клиентов, после которого поведение стало следующим: подключиться было возможно только после 5-8 попыток. Продолжительное прослушивание «выбивало» клиента и вещание останавливалось при использовании плеера без функций переподключения (например, браузерный html5). Сразу же подумалось именно на разницу двух icecast2. Разница была найдена — именно в том, что ранее использовался форк kh. Поставили последний форк с той же конфигурацией — клиенты пошли подключаться выше предела в N-подключений.
Для статистики:
самый популярный маунт на текущий момент имеет рекорд в 7963 слушателей
сумма онлайна остальных маунтов станций примерно 7-8 тысяч слушателей
количество текущих потоков — 60 (15 станций, 4 формата), без учета служебных
Тоже вещаем в этой связке. Можно занести в подводные камни:
1. liquidsoap при внесении в 1 конфиг более 15 потоков начинает выдавать в эфир миллисекундные затыки звучания. Слышни, ужасны. Поэтому лучше иметь в виду, что при большой его нагрузке будет необходимо запускать несколько копий.
2. icecast2 стандартный не держит онлайн более ~3000 соединений. У вас максимум клиентов в конфиге выставлено 100. Если упретесь во что-то неведомое — меняйте icecast2 на сборку kh. Сайт сборки — www.xiphicecast.webspace.virginmedia.com/
3. Мыло собирали из latest stable сайта, а не из репозиториев, т.к. необходимой для нас поддержки aac+ нет в стандарте. Это для Ubuntu Server.
Ну и для полноты статьи, мини-конфиг для upstart:
description "air-st"
start on (
net-device-up
local-filesystems
and runlevel [2345]
)
stop on runlevel [016]
respawn
exec su - liquidsoap -c "/usr/local/bin/liquidsoap /etc/liquidsoap/st.liq"
Стандартно service air-st start/stop/restart (st — краткое название одной из станций. Удобно перезапускать их независимо).
Правила безопасности всегда составляются индивидуально. Обжигаются когда их было недостаточно, замедляют время работы когда они избыточны. Поэтому всегда разговор об идеальной схеме работы заканчивается решением руководствоваться только здравым смыслом.
Аппроксимируя мысль в целом можно сказать, что основная идея безопасной схемы — продуманная архитектура. Когда весь сервис будет доступен в полном или ограниченном режиме всегда. И если все таки не будет доступен, то сможет сказать о проблемах сам или с помощью наблюдающих.
Слово «современность» часто бывает отпугивает потенциальных теть Галь, которые руководствуются тем, что «компьютер у меня уже 5+ лет, он не потянет современность». Поэтому, как мне кажется, правильнее использовать «обновленную версию». Конечно же, указав при этом, что обновленные версии безопаснее и быстрее. Остальное то же самое (слово «удобно» — тоже часто отпугивает теть Галь, ибо она «так привыкла и все нравится»).
И делаться он должен приятной знакомой/девушкой в качестве подарка, которая ничего не понимает в админстве. В частности, крайне старую фразу «я конфеты не пью», относящуюся в данном контексте к несоответствию устоявшегося образа админа любителя сладкого.
Если делать самому, то креативнее, как мне кажется, сделать кружку из витой пары (обжать, конечно же), загерметизировать чем-то пищевым (силикон ведь не подойдет?) и в это ужасное творение с лицом опытного игрока в покер, не отрывая взгляд от монитора, залить только что подаренную бутылочку хеннеси в это созданное сооружение. Пить с видом как обычное пиво. Собственно, мысль навеяна одной из историй на баше (или итхаппенсе. не помню, век не заходил).
На сколько (плохо) я знаю устройство ядерных реакторов там, скорее всего, разнесет все гораздо быстрее, если именно выключить какое-либо звено в нем. Причем, вроде как единственно важная система в ядерном реакторе — его охлаждение.
Понимаю, что вам уже много высказали ценных и эмоциональных комментариев, но не могу не внести свой скромный вклад.
При таком варианте аналогично провайдеру могут прислать письмо с просьбой закрыть доступ пользователям к данному ресурсу (домену или IP адресу). Из истории непонятно как происходило это далее, но предположу два варианта: 1) провайдер просто выполнил просьбу и заблокировал или заведомо уведомив владельца или постфактум; 2) провайдер попросил владельца ресурса принять меры для законного разрешения конфликта, оговорив владельца ресурса определенный срок.
При обоих ситуациях моими первыми шагами было бы разобраться с провайдером. Первое — получить письменный вариант просьбы или распоряжение на закрытие. Второе — обратиться в полицию за разъяснениями. В случае, если провайдер самостоятельно закрыл ресурс — потребовал его открытия. Если провайдер отказывается снять блокировку — обращение в полицию с заявлением на провайдера. В случае, если провайдер выделил срок для разрешение ситуации — разбирался бы с полицией, уведомляя о продвижении разрешения вопроса провайдера.
Что касается вопросов с полицией. Здесь начинается почти стандартный квест. Ищем подходящего адвоката (имеет смысл поискать даже на хабре), изучаем аспекты законодательства, разбираемся с полицией по составленному плану (с этого момента все расходы средств и времени тщательно фиксируем чеками и иными документами).
Есть вариант, что полиция при подобном подходе закроет конфликт. Здесь уже не знаю, есть ли возможность потребовать возмещение материальный затрат. Я не юрист. Есть вариант долгих разбирательств, последующего суда. Здесь уже можно легко опираться на практику подобных дел в мире.
Самая неприятная в этой ситуации — потраченное бесценное время, в которое придется пропускать работу или даже совсем на время ее не посещать. В зависимости от компании, где вы работаете, могут появиться ситуации, когда вам могут предложить дать время на разбирательства с увольнением (уже не суть, с последующим приемом или нет). Если денег на жизнь и расходов адвоката не хватит, то по уже описанному вами поведенияю лично я бы с удовольствием поделился своими кровными за поддержание идеи, которую разделяю сам. Если компания дает время заниматься проблемой без ущерба зарплате и отпуску — все замечательно. В иных ситуациях стоит задуматься о смысле находиться в штате подобной компании. Понимаю, Воронеж может не такой город, где имея хорошие знания легко устроиться на работу, но выход с подобно ситуации я бы хотя бы очень постарался найти правовой.
Что касается особистов, фсб и прочей нечисти, которая нередко терроризирует не только народ, но и страну, то, как я считаю, в этом деле будет решать фактор записывать или даже снимать все, что касается этих ребят. Причем, освещать всю эту информацию публично. Это снова решающий фактор. При каких-либо проблемах (набьют морду, сломают руку) — у ребят будут крайне серьезные проблемы с поддержкой вас большого числа народа. А проблемы серьезнее для вас делать смысла нет.
В который раз настроение ухудшается от того, что некоторое время активно пользовался соц. сетями. Так неприятно, когда о каждом можно узнать так много информации.
Как рассчитывается адекватная стоимость чайника, нагревающего объем воды X за время Y, имеющего возможность улучшить водонагревательный элемент до коэффициента Z? Как рассчитать стоимость и «сложность добычи» спирали с заданными характеристиками? Как рассчитать стоимость водонагревательного чана на 300 литров, который (в игре) своим присутствием не сделает чайники ненужными?
Из того, что я слышал в общих чертах на примере mmorpg: стоимость новой палки X рассчитывается исходя из времени (-необходимого для достижения палки похуже; — необходимого игроку для прокачки умения, которое эта палка игнорирует).
Методика тестирования была следующая: новый сервер вещания был развернут в другом ДЦ (латест стэйбл убунта, icecast2 из пакетов). В конфигурации было установлено ограничение в миллион клиентов. Включили все потоки (на тот момент их было 56). Обновили ДНС-записи на новый сервер. Пошла нагрузка, мониторили онлайн плагином icecast2 к munin. Был достигнут суммарный онлайн в N-клиентов, после которого поведение стало следующим: подключиться было возможно только после 5-8 попыток. Продолжительное прослушивание «выбивало» клиента и вещание останавливалось при использовании плеера без функций переподключения (например, браузерный html5). Сразу же подумалось именно на разницу двух icecast2. Разница была найдена — именно в том, что ранее использовался форк kh. Поставили последний форк с той же конфигурацией — клиенты пошли подключаться выше предела в N-подключений.
Для статистики:
самый популярный маунт на текущий момент имеет рекорд в 7963 слушателей
сумма онлайна остальных маунтов станций примерно 7-8 тысяч слушателей
количество текущих потоков — 60 (15 станций, 4 формата), без учета служебных
1. liquidsoap при внесении в 1 конфиг более 15 потоков начинает выдавать в эфир миллисекундные затыки звучания. Слышни, ужасны. Поэтому лучше иметь в виду, что при большой его нагрузке будет необходимо запускать несколько копий.
2. icecast2 стандартный не держит онлайн более ~3000 соединений. У вас максимум клиентов в конфиге выставлено 100. Если упретесь во что-то неведомое — меняйте icecast2 на сборку kh. Сайт сборки — www.xiphicecast.webspace.virginmedia.com/
3. Мыло собирали из latest stable сайта, а не из репозиториев, т.к. необходимой для нас поддержки aac+ нет в стандарте. Это для Ubuntu Server.
Ну и для полноты статьи, мини-конфиг для upstart:
Стандартно service air-st start/stop/restart (st — краткое название одной из станций. Удобно перезапускать их независимо).
Аппроксимируя мысль в целом можно сказать, что основная идея безопасной схемы — продуманная архитектура. Когда весь сервис будет доступен в полном или ограниченном режиме всегда. И если все таки не будет доступен, то сможет сказать о проблемах сам или с помощью наблюдающих.
Не работает при блокировке.
Если делать самому, то креативнее, как мне кажется, сделать кружку из витой пары (обжать, конечно же), загерметизировать чем-то пищевым (силикон ведь не подойдет?) и в это ужасное творение с лицом опытного игрока в покер, не отрывая взгляд от монитора, залить только что подаренную бутылочку хеннеси в это созданное сооружение. Пить с видом как обычное пиво. Собственно, мысль навеяна одной из историй на баше (или итхаппенсе. не помню, век не заходил).
При таком варианте аналогично провайдеру могут прислать письмо с просьбой закрыть доступ пользователям к данному ресурсу (домену или IP адресу). Из истории непонятно как происходило это далее, но предположу два варианта: 1) провайдер просто выполнил просьбу и заблокировал или заведомо уведомив владельца или постфактум; 2) провайдер попросил владельца ресурса принять меры для законного разрешения конфликта, оговорив владельца ресурса определенный срок.
При обоих ситуациях моими первыми шагами было бы разобраться с провайдером. Первое — получить письменный вариант просьбы или распоряжение на закрытие. Второе — обратиться в полицию за разъяснениями. В случае, если провайдер самостоятельно закрыл ресурс — потребовал его открытия. Если провайдер отказывается снять блокировку — обращение в полицию с заявлением на провайдера. В случае, если провайдер выделил срок для разрешение ситуации — разбирался бы с полицией, уведомляя о продвижении разрешения вопроса провайдера.
Что касается вопросов с полицией. Здесь начинается почти стандартный квест. Ищем подходящего адвоката (имеет смысл поискать даже на хабре), изучаем аспекты законодательства, разбираемся с полицией по составленному плану (с этого момента все расходы средств и времени тщательно фиксируем чеками и иными документами).
Есть вариант, что полиция при подобном подходе закроет конфликт. Здесь уже не знаю, есть ли возможность потребовать возмещение материальный затрат. Я не юрист. Есть вариант долгих разбирательств, последующего суда. Здесь уже можно легко опираться на практику подобных дел в мире.
Самая неприятная в этой ситуации — потраченное бесценное время, в которое придется пропускать работу или даже совсем на время ее не посещать. В зависимости от компании, где вы работаете, могут появиться ситуации, когда вам могут предложить дать время на разбирательства с увольнением (уже не суть, с последующим приемом или нет). Если денег на жизнь и расходов адвоката не хватит, то по уже описанному вами поведенияю лично я бы с удовольствием поделился своими кровными за поддержание идеи, которую разделяю сам. Если компания дает время заниматься проблемой без ущерба зарплате и отпуску — все замечательно. В иных ситуациях стоит задуматься о смысле находиться в штате подобной компании. Понимаю, Воронеж может не такой город, где имея хорошие знания легко устроиться на работу, но выход с подобно ситуации я бы хотя бы очень постарался найти правовой.
Что касается особистов, фсб и прочей нечисти, которая нередко терроризирует не только народ, но и страну, то, как я считаю, в этом деле будет решать фактор записывать или даже снимать все, что касается этих ребят. Причем, освещать всю эту информацию публично. Это снова решающий фактор. При каких-либо проблемах (набьют морду, сломают руку) — у ребят будут крайне серьезные проблемы с поддержкой вас большого числа народа. А проблемы серьезнее для вас делать смысла нет.
Спасибо, что прочитали.