Я работаю в конторе, которая делает а основном онлайн-игры. Но я над смежной задачей работаю, но использую наработки из движка игры. Знаю, что игроделы у нас используют Celery + RabbitMQ. Celery умеет делать отложенные задачи. Если надо — могу поподробнее расспросить в понедельник…
Эх, что-ж вы так… Основная соль XSLT как раз в большом наборе template-ов и apply-templates. Можно очень сложные трансформации строить вообще без for-each — ей и почти без if и choose только за счет темплейтов.
>При отказе сервера клиенты должны это распознать и вывести сообщение, после этого завершив работу.
>При отказе основного сервера клиенты должны переключится на альтернативный сервер сохранив состояние.
Так что должен сделать клиент при отказе сервера? Помереть или переключиться?
Если это правда полная формулировка, то причем здесь фибоначи и GRID вычисления на клиентах?
Зависит от счетчика конечно, но 99% счетчиков считают сколько раз его загрузили и с какой странички. (Ну, плюс всякие там версии браузера, ОС, разрешение экрана и прочую хрень)
я так понимаю там схема хитрее — история хранится у каждого из собеседников. Когда оба собеседника онлайн, они сверяют историю между собой. Если есть различия, то синхронизируются. А вот если оба собеседника подключатся не теми клиентами, через которые в прошлый раз переписывались, то истории не будет.
kill SIGHUP <pid>и хабр поломался из за угловых скобок