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

====== Проекты ====== В этой статье я постарался перечислить проекты, в реализации которых мне довелось принять участие. Я намеренно не углублялся в техническое описание, чтобы текст не выглядел совсем занудным. ===== Программы для мобильных телефонов ===== ==== Игрушки Cascata ==== В конце 2003 года вместе с моим другом и бывшим однокурсником Сергеем Бахметьевым начали писать игрушки для английской компании Cascata. Со стороны Cascat-ы с нами общался [[http://www.allaboutsymbian.com/features/item/Ewan_Meets_Neil_Wooding_of_Cascata_Games.php|Neil Wooding]]. На них была основная концепция, графика и распространение, а на нас - разработка. Этот проект можно считать успешной иллюстраций принципа : Хочешь изучить технологию - начни делать что-либо с ее помощью. Даже более того, прелести этого принципа нам пришлось вкусить дважды: первый раз - с Symbian OS, второй - с J2ME. (Слегка подумав, я пришел к выводу, что данный принцип сопутствует всем моим проектам, а не только этому). Если первые две игрушки мы писали под один класс телефонов, то остальные пришлось писать под разношерстный "зоопарк" моделей нескольких производителей. Это добавило поводов пошевелить мозгами. Еще один важный принцип необходимость, которого ярко высветил этот проект: Необходимо идти на компромиссы. Выбирать каким аспектом программы нужно пожертвовать ради другого. Конечно, это не очень актуально, если у вас есть неограниченные ресурсы. Но в тут мы часто сталкивались с суровой реальностью, ограничение на размер [[wpru>мидлет|мидлета]], памяти или быстродействие устройства. === Pinball Challenge === {{ :projects:pinball-about.png?88|Окно About}} {{ :projects:pinball-back.png?88|Фон игрового поля}} {{ :projects:pinball-splash.png?88|Начальная заставка}} Целевой платформой была [[wpru>S60]], телефоном, на котором велась вся отладка - [[http://www.forum.nokia.com/devices/7650|Nokia 7650]]. На телефоне - [[wpru>Symbian OS]] версии 6.1. Разрешение экрана - 176х208. Wow!((Не забывайте - на дворе стоял 2003 год)). Язык программирования - C++. Перед началом разработки попробовали найти другие реализации [[wpru>пинбол|пинбола]] для мобильных телефонов. Действительно, нашли несколько игрушек для мобильных телефонов, в названии которых присутствовало слово "пинбол". Но ни в одной из них шарик не двигался по параболе, игрушки скорее напоминали [[wpru>арканоид]], шарик двигался линейно и равномерно. Это вселяло надежду, что наша игрушка будет выделяться на фоне остальных. Математическая модель была на мне и, повозившись с математикой, я принял следующую: * Шарик представляется только своей центральной точкой, а все стенки и прочие препятствия "раздуваются" на радиус шарика. Это позволило избавиться от большого количества операций на каждом шаге расчётов. * Все стенки представлены в виде набора отрезков и окружностей. Отрезки направленные, т.е. для каждого из них можно сказать, с какой стороны от него находится игровое поле, а с какой стенка. Делается это просто, если смотреть на отрезок со стороны игрового поля, то первая точка, задающая отрезок, должна быть слева, а вторая - справа. Все окружности выпуклые. Была мысль оставить одну вогнутую окружность (вернее, дугу) для дальней стенки игрового поля, но эскиз поля у нас изначально был без этой дуги, так что не пришлось утяжелять расчёты. * Флипперы - единственные подвижные части((корме самого шарика, разумеется)). Каждый из них представлен отрезком верхней поверхности и окружностью у ближайшего к центру поля конца. * Для каждого элемента (отрезка или окружности) задан коэффициент поглощения энергии. У бамперов((круглых тумб посреди поля)) этот коэффициент больше единицы, при столкновениях с ними шарик набирает скорость. У прочих поверхностей меньше единицы ((Кстати, поначалу мне не казалось очевидным, то, что обычные поверхности должны гасить скорость шарика. Но когда я попробовал запустить пинбол с абсолютно упругими станками, то понял, что играть в него совершенно невозможно, шарик как сумасшедший носился по полю)) * Время разбито на отрезки. В начале отрезка к текущей скорости шарика прибавляется вектор ускорения направленный вниз. Далее считается, что на протяжении всего отрезка шарик движется линейно. Такое огрубление позволило существенно облегчить расчёты и совершенно не заметно на глаз, ведь порядок погрешности составляет доли пикселя. * На каждом шаге определяется, столкнется ли шарик с каким-либо препятствием за текущий отрезок времени. Перебираются все элементы поля: отрезки и окружности, проверяется, не пересечётся ли шарик с ними. Если да, то вычисляется момент времени столкновения, новые координаты шарика и его скорость. И запускается пересчет на более коротком отрезке времени. Неподвижные флипперы обрабатываются точно также как и стенки, для подвижных флипперов вычисляется момент и место столкновения с шариком, а также дополнительный импульс, передаваемый шарику. * Вычисления производились над числами с фиксированной точкой. Для этого был написан свой класс. Значения хранились в 32-х разрядном целом, последние 5 бит рассматривались как дробную часть. Это позволило с одной стороны использовать быструю целочисленную арифметику, а с другой - сохранить приемлемую точность. Кроме Nokia 7650 игра была протестирована на 3600, 3650 и даже на только что запущенном с большой помпой N-Gage. <html> <div class="clearer"></div> </html> ~~REFNOTES~~ === Ryan Giggs Pinball Challenge === {{ :projects:pingiggs-hi_score.png?88|Таблица лучших результатов}} {{ :projects:pingiggs-menu.png?88|Основное меню}} {{ :projects:pingiggs-splash.png?88|Начальная заставка}} Нейл с гордость сообщил нам, что приобрел права на использование образа [[wpru>Гиггз_Райан|Райана Гиггза]] из "Манчестер Юнайтед" в нашей игрушке. Я не большой фанат футбола, и в тот момент даже не знал, кто это такой, но быстренько поднял информацию в интернете и был очень впечатлён. Я даже подумывал пойти на матч, который в ту осень проводил "Манчестер Юнайтед" в Москве, но так и не собрался. <html> <div class="clearer"></div> </html> Кроме чисто косметических изменений (заключавшихся в использовании фотографий Гиггза) в игре появился новый элемент. {{ :projects:pinball-rol2.gif|Катающийся мячик}} Вместо скучного стального шарика {{:projects:pinball-ball.png|шарик}} по полю катается маленький футбольный мячик {{:projects:pingiggs-ball.png|мячик}}. Именно **катается**, а не скользит как плоская шайба с нарисованными на ней чёрными пятнышками. <html> <div class="clearer"></div> </html> ~~REFNOTES~~ === Basil Brush. Quest for the stolen Joke Book === {{ :projects:bb-about.png?88|Окно About}} {{ :projects:bb-background.png?88|Фон для свитков с шутками}} {{ :projects:bb-splash.png?88|Начальная заставка}} Естественно, я не знал, кто такой [[wp>Basil Brush]]. Оказывается, это кукольный лисёнок, который участвует в очень популярном английском ТВ-шоу. По узнаваемости для англичан его можно сравнить с Ириской и Клёпой из АБВГДейки для людей моего поколения. Он много шутит и производит при этом звук "Boom! Boom!". Собственно, для нас история персонажа была не так важна. В игрушке всё сводится к тому, что лисёнок путешествует по лабиринту, разбитому на уровни. Цель лисёнка собрать на каждом уровне части "книги шуток". На уровнях встречаются враги, которых можно отстреливать из водяного пистолета. Ко всему прочему уровни разбросаны по разным эпохам: средневековью, древнему Египту, доисторической эре с ящерами и будущему с роботами. <html> <div class="clearer"></div> </html> Эту и две последующие игрушки мы делали под J2ME. В то время (начало 2004 года) телефоны если и поддерживали Java, то в основном [[wpru>MIDP]] 1.0 плюс различные для разных производителей телефонов. Основные различия касались воспроизведения звука, ну и других нюансов хватало. Начать с того, что размеры экрана разнятся от 128х128 до 176х208. Кто-то поддерживает полноэкранный режим, кто-то нет. Один телефон поддерживает одни форматы звуковых файлов, другой - совсем другие. Особенно много нервов отнял такая особенность одного из телефонов: мы никак не могли заставить воспроизводить его картинки PNG с прозрачными участками, в итоге оказалось, что цвет, соответствующий прозрачному, должен быть обязательно белым. В общей сложности мы адаптировали под следующие платформы: ^Платформа ^Типичные телефоны ^ |Vodafone |Sharp GX10, GX20 | |Series 60| Nokia 7650 | |Series 40| Nokia 7210 | |Motorola | Motorola V300, V525, V600 | |Sagem | Sagem myV-65, myV-75 | Чтобы не погрязнуть в параллельных версиях для разных телефонов, мы вынесли основную игровую логику в отдельную часть, которая, взаимодействовала с классами некоего абстрактного устройства. А классы этого абстрактного устройства для каждого телефона написали уже свои. Надо отметить, что это сильно облегчило нам жизнь. Для всех вышеперечисленных телефонов производители представляют разработчикам эмуляторы. Сначала мы отлаживали программу на именно на них, а после этого уже на телефонах. Части телефонов мы с Серёгой даже в глаза не видели, они были в Англии у Нейла. Мы выкладывали готовую версию мидлета на свой сайт, Нейл устанавливал его на телефон и проверял. После отладки нужно было еще подготовить JAD и JAR файлы для операторов: Vodafone и Orange. В основном их требования сводились к тому, как должен называться мидлет и к тому, какие поля должны содержаться в JAD. Но кроме этого, у операторов работали команды тестировщиков, которые присылали нам отчёты по работе самой программы, о багах и том, соответствует ли поведение программа перечню их требований. {{:projects:bb-map-v300.png?144 |плитки карты для Motorola v300}} {{ :projects:bb-map-gx10.png?120|плитки карты для Sharp gx10}} Я уже говорил о компромиссах, вот тут столкнулись с их необходимостью лицом к лицу. Мало того, что всю графику, предоставленную Нейлом, приходилось оптимизировать, так для Nokia 7210, чтобы ужать размер мидлета до разрешённых 64K пришлось целиком убрать египетский уровень. У Sharp gx10 ограничение послабее - 80К, но и в версии для него египетский уровень отсутствует. На рисунке слева приведен набор плиток, используемый для отрисовки лабиринтов в Motorola v300, а справа - более чем в два раза порезанный набор для gx10. Кроме самих мидлетов для мобильных телефонов мы написали ряд вспомогательных программ, таких как редактор уровней и пр. <html> <div class="clearer"></div> </html> ~~REFNOTES~~ === Corral === {{ :projects:corral-about120.png?88|Окно About}} {{ :projects:corral-menu120.png?88|Основное меню}} {{ :projects:corral-splash120.png?88|Начальная заставка}} Пожалуй, самая приятная игрушка из этой серии. По крайней мере для меня. Ведь она "пошаговая", нет необходимости постоянно смотреть на экран, можно спокойно уделить внимание окружающим, если они того просят, в игре при этом никто не пострадает :-) Игра ведётся на поле 5х5. На поле есть одна корова и несколько овец. Каждое животное можно толкнуть в одну из четырёх сторон, при этом оно будет скакать пока не уткнётся в какое-нибудь другое животное. А если не уткнётся, то убежит с пастбища, и даже хиленькая загородка его не остановит, поэтому вот так "в никуда" животных отправлять запрещено. Цель игры -- загнать единственную корову на центральную клетку. При разработке пришлось столкнуться с такими же трудностями как и в предыдущей игре, и также успешно с ними справиться. //(Хм. Только сейчас, при написании статьи, я точно узнал значение слова [[wp>Corral]]. До этого воспринимал это слово, просто как что-то связанное с овцами или коровами)// <html> <div class="clearer"></div> </html> ~~REFNOTES~~ === Del Boy's Street Car Challenge === {{ :projects:delboy-about120.png?88|Окно About}} {{ :projects:delboy-start120.png?88|Заставка перед уровнем}} {{ :projects:delboy-splash120.png?88|Начальная заставка}} Герой сериала [[wp>Only_Fools_and_Horses]] Дел Бой колесит на своем жёлтом трехколёсном автомобильчике [[wp>Reliant Regal]] по [[wp>Peckham|Пекему]] - пригороду Лондона. <html> <div style="clear:both;"></div> </html> {{http://upload.wikimedia.org/wikipedia/commons/f/f4/Peckham_landscape.jpg?100 |Типичный вид Пекема}} {{http://upload.wikimedia.org/wikipedia/en/4/41/Only_Fools_and_Horses_car.jpg?100 |Тот самый желтый автомобиль}} Нейл прислал графику достаточно похоже отображающую как сам пригород Лондона, так и знаменитую машину Дела Боя. Дорожки в игре двунаправленные. Если выехать на "неправильную" сторону, то за тобой начинают гоняться полицейские. Заметьте, игрушка писалась для Англии, а там "правильная" сторона - левая. Когда я сам игрался, то как раз это было самым сложным -- придерживаться левой (непривычной для нас стороны). <html> <div style="clear:both;"></div> </html> ~~REFNOTES~~ ==== Сервис IslamicFon ==== {{ :projects:islamicfon-logo.gif?135}} В 2006 году я встретил Билала Дыбашева, который вынашивал идеею проекта ИсламикФон. В ноябре 2006 года сервис ИсламикФон был запущен. Изначально предполагалось брать плату за использование сервисом, но позже было принято решение сделать его бесплатным, каким он и является в настоящий момент. В сентябре 2009 года было загружено более 12 тысяч расписаний. Получить клиентскую программу для мобильного телефона можно с сайтов [[http://www.islamicfon.com]] и [[http://wap.islamicfon.com]]. <html> <div class="clearer"></div> </html> === Суть проекта === {{ :projects:image0b.png?88}} В исламе существуют пять обязательных ежедневных молитв - [[wpru>Намаз|намазов]]. Время молитв привязано к положению солнца на небосводе. И, соответственно, эти времена разные для разных районов земли. И даже для конкретного района эти времена смещаются в течение года из-за изменения продолжительности солнечного дня. Существуют программы как для компьютеров, так и мобильных телефонов, которые по широте и долготе вычисляют расписание молитв для любой точки земли. Но, как правило, такие расписания не совпадают с теми, что используются в местных мечетях. Расхождения могут достигать нескольких минут. Основная идея проекта заключается в том, чтобы собирать на одном сервере именно расписания молитв, которые считаются правильными в местных мечетях. А клиентские программы должны периодически получать эти расписания с сервера. Кроме того, клиентская программа должна автоматически запускаться при наступлении времени очередной молитвы и воспроизводить звуковой файл. <html> <div style="clear:both;"></div> </html> === Техническая реализация === Реализация естественным образом разделяется на серверную и клиентскую части. Транспортом для передачи данных между частями был выбран HTTP. С самого начала было ясно, что проект будет расширяться: будут добавляться города, звуковые файлы. В связи с этим было решено, что в клиентской программе на телефоне не должны "жёстко" прошиваться списки городов и звуковых файлов. Вместо этого такие списки должны доставляться от сервера к клиенту по тому же протоколу HTTP. Такая концепция позволяет избежать смены клиентской программы при включении сервиса в новом городе. Доставку месячного расписания изначально предполагалось сделать с оплатой по SMS. Для этого и клиентская, и серверная части должны взаимодействовать с SMS-агрегатором. Это повлияло на то, что сессия по доставке расписания разбита на три следующих шага: - Проверка существования расписания. * Клиентская программа на телефоне формирует запрос на проверку, есть ли на сервере расписание для заданных города и месяца. Отправляет его по HTTP на сервер. * Сервер проверяет, есть ли у него нужное расписание. Если да, то сервер направляет клиенту подтверждение. Если нет, то посылает отрицательный ответ, и клиент прекращает дальнейшие действия. - Посылка SMS. * Клиентская программа формирует SMS и отправляет его на выбранный короткий номер. * SMS через одного из операторов мобильной связи попадает к агрегатору. Он в свою очередь формирует HTTP-запрос к нашему серверу. * Наш сервер принимает этот запрос. В своём HTTP-ответе сервер формирует благодарственное сообщение клиенту. * Агрегатор пересылает благодарственное сообщение в виде SMS на номер клиента. - Передача расписания. * Клиентская программа формирует запрос на расписание для заданных города и месяца и отправляет его серверу на HTTP. * Сервер отсылает клиенту запрошенное расписание. Более года сервис работал в платном режиме. Затем руководитель проекта решил перевести его на бесплатный режим. Сессии доставки расписания стали двух-этапными (из них был выключен второй этап с SMS). Причем, для клиентов этот переход прошел прозрачно, им не пришлось менять приложение на своих телефонах. ~~REFNOTES~~ == Серверная часть == Серверная часть реализована на связке [[wpru>LAMP]] - Linux((в качестве операционной системы)), Apache((как web-сервер)), MySQL((База Данных)), PHP((язык программирования)). В состав этой части входят три отдельных web-сервера: - **Основной**, в задачи которого входят ответы на запросы от клиентского j2me-приложения: * выдать список городов, * выдать список звуковых файлов, * передать определённый звуковой файл, * проверить наличие расписания (шаг 1 в схеме сессии, описанной в предыдущем параграфе), * ответить на HTTP-запрос от агрегатора (шаг 2 там же), * передать расписание (шаг 3 там же). - **Рабочее место администратора**, который предоставляет web-интерфейс для выполнения задач: * работа со списком городов, * работа с расписаниями, * работа со звуковыми файлами, * управление служебными параметрами, такими как короткий номер и префикс sms и пр. - **CMS** для информационных сайтов [[http://www.islamicfon.com]] и [[http://wap.islamicfon.com]]. ~~REFNOTES~~ == Клиентская часть == Приняв во внимание опыт работы с "зоопарком" моделей телефонов, было решено писать приложение только под устройства, поддерживающие MIDP 2.0. Тем более что к 2006 году все телефоны с Java поддерживали MIDP 2.0 за очень редким исключением. Таким образом, я писал **одно** приложение для всех телефонов. Для адаптации к разным размерам в midlet-е хранится 4 набора графики для разных экранов (шириной от 128 до 352 пикселей). Звуковые файлы также представляли некоторую проблему -- разные телефоны поддерживают разные типы файлов. Например, оказалось, что весьма продвинутый SonyEricsson P800 не поддерживает ''audio/mpeg''. Эту трудность удалось обойти, отказавшись от хранения звукового файла в JAR-файле самого приложения. Вместо этого, после установки приложения на телефон пользователь может выбрать, какой из хранящихся на сервере звуковых файлов загрузить в RMS (Record Management System). Это с одно стороны позволило уменьшить размер JAR-файла, а с другой - гибко выбирать размер и тип звукового файла. Ряд функций в нашем приложении, таких как обращение к внешнему серверу, запуск приложения по расписанию и уж тем более - отправка SMS разработчики Java считают потенциально опасными. Для того чтобы j2me-приложение их выполняло без вывода на экран запросов на подтверждение операции, это приложение должно быть "подписано" (signed). Это значит, что приложение должно быть подписано сертификатом, выданным авторитетной организацией разработчикам приложения. По сути, это те же сертификаты ssl, необходимые для работы сайтов HTTPS. Для производителей сотовых телефонов авторитетными организациями являются [[http://www.verisign.com/code-signing/|VeriSign]] и [[http://www.thawte.com/code-signing/|Thawte]]. Сигнатуры именно этих [[wpru>центр сертификации|центров сертификации]] (Certification authority, CA) производители прошивают в свои телефоны ((к сожалению, разные производители предпочитают разные CA)). Мы решили получить сертификаты VeriSign и Thawte, и сделать две версии приложения, подписанные одним и другим. У Thawte оказалось российское представительство в лице РБК. Правда, мы оказались первыми, кто обратился к ним за получением сертификата для подписи java-приложений (основной их хлеб - это ssl-сертификаты). Так что, в процедурах получения пришлось разбираться совместно. У VeriSign в России представительства нет. Но здесь, как мне показалось, всё прошло даже более гладко. После отправки им пакета документов, они сделали несколько контрольных звонков. Причем, общаться пришлось с русскоговорящими сотрудниками VeriSign, что приятно. С переходом сервиса на бесплатный режим сертификаты было решено не продлевать, так что в настоящий момент распространяется неподписанный вариант приложения. Попавшиеся на пути разработки ухабы: * **Полупрозрачность изображений** корректно отрабатывается только такими грандами как Nokia и SonyEricsson. Во избежание проблем, используем картинки либо полностью прозрачными пикселями, либо, наоборот, полностью непрозрачними. * **PushRegistry**, используемый для запуска приложения в определённое время. На телефонах Series 40 данная функция реализована весьма забавно. В указанное время на экране телефона высвечивается запрос "запустить приложение?"((Я могу сравнить это с поведением будильника, спрашивающего в нужное время "зазвонить?")). Ну что ж, обладателям таких телефонов придется смириться, это [[http://wiki.forum.nokia.com/index.php/KIJ000394_-_PushRegistry_confirmation_on_Series_40_MIDlets|не лечится]]. На телефонах Series 60 я столкнулся с другой [[http://wiki.forum.nokia.com/index.php/KIJ000324_-_Inaccuracy_in_PushRegistry.registerAlarm()_method|"особенностью"]]. Если приложение должно стартовать через более чем 30 минут, то оно запускается гораздо раньше назначенного срока. С этим поборолся просто: запустившись приложение проверяет время и если нужное не еще не наступило, то оно закрывается предварительно перевыставив время "подъёма". ~~REFNOTES~~ <html><!-- [[jsr>jsr135| Mobile Media API (JSR-135) ]] RMS javax.microedition.rms javax.microedition.lcdui.game MIDP 2.0 JSR-118 network javax.microedition.io.PushRegistry Wireless Messaging API JSR-205 --></html> ==== PictFont - Рисованные шрифты ==== {{ :projects:pictfont100.png|логотип PictFont}} В каждом проекте, из перечисленных выше, приходилось выводить текст своими шрифтами. Стандартные методы используемые в классе ''javax.microedition.lcdui.Font'' не позволяют работать с какими-либо шрифтами, отличными от тех, что производитель телефона "зашил" в него. А хочется (особенно в игрушках) чтобы надписи выглядели красиво, и именно так, как ты задумал. Сама идея, как работать со своим шрифтами возникла еще в первых проектах. И с небольшими изменениями её реализация этой идеи кочевала от проекта к проекту. Суть ее в том, что нужно - нарисовать картинку, на которой будут все нужные символы, - положить ее в jar-файл midlet-а, - во время работы midlet-а в нужное время в нужном месте отрисовывать нужный кусочек этой картинки. <html><div class="clearer"></div></html> И вот, наконец, в начале 2010 года сразу после новогодних каникул я решил оформить эту идею в виде библиотеки, которую собираюсь использовать в последующих проектах. {{ http://sflogo.sourceforge.net/sflogo.php?group_id=299995&type=10&.png?}} Более того, я надеюсь что, эта библиотека будет полезна еще кому-то. Возможно, кто-то поможет улучшить ее. Поэтому я решил с самого начала разместить этот проект на **[[wpru>SourceForge]]** - сайте разработчиков открытого программного обеспечения. Ознакомится с библиотекой и следить за развитием проекта можно на площадке SourceForge: * [[http://sf.net/projects/pictfont/]] - описание проекта * [[http://pictfont.sf.net/]] - домашняя страница проекта {{:projects:tramp1.gif |Топочущий текст}} Картинка с "топочущими буквами" снята с midlet-а, размещенного мною в качестве примера в [[https://sourceforge.net/projects/pictfont/files/|хранилище]] на SourceForge. Смотрите там файл ''exam1-trampfont.tar.gz''. Или можете загрузить этот пример непосредственно на телефон, зайдя браузером телефона на [[http://pictfont.sf.net/wap/]], и выбрав для скачивания Example 1 - Tramping font. //(Бонус для скачавших приложение на свой телефон - Вы узнаете не только кто [[wp>The_quick_brown_fox_jumps_over_the_lazy_dog|прыгает через ленивую собаку]], но и почему [[wpru>Панграмма|шеф взъярён]] :-) )// <html><div class="clearer"></div></html> ===== Сетевые проекты ===== При написании я был в раздумье, как назвать эту часть статьи. Если проекты описанные выше имели четкие временные границы, то проекты, которые я хочу описать сейчас, являются "долгоиграющими". Многие из них по времени сильно пересекаются друг с другом. Все они так или иначе связаны с моей основной работой. А поскольку она связана с построением и развитием сетей, то и раздел я назвал "сетевые проекты". ==== Общие черты проектов ==== Начиная с 1997 года, мне довелось участвовать в строительстве и поддержке нескольких сетей. Самая первая из них содержала полсотни маршрутизаторов, разбросанных по Москве, и десяток в Питере. (Забавно, что такое виртуальное присутствие в Питере началось за пару лет до того, как я впервые физически побывал в нем сам). Потом последовали проекты по построению сетей в московской области. Они представляют собой корпоративные сети, в каждой из которых присутствует порядка 60-80 объектов. Кроме передачи данных, по этим сетям передается голосовой (VOIP) трафик внутренних телефонов. Характер моей работы не связан с выездами на объекты. При установке нового оборудования я либо настраиваю его в нашем офисе, либо готовлю конфигурацию, которую в оборудование на месте "зальют" сотрудники наших разъездных бригад. Обычно это минимальная конфигурация, позволяющая "подхватить" устройство из нашего офиса, и все дальнейшие тонкие настройки я произвожу уже со своего рабочего места. Хозяйства получаются большими, и вручную с ними справляться тяжело, а посему обычно для каждой сети заводится управляющий сервер (а иногда и не один). На этих серверах мы разворачиваем инструменты, позволяющие облегчить нашу работу по поддержанию сети. А поскольку никто лучше нас не знает наши задачи, то и инструменты мы пишем чаще всего сами. Кроме того, необходимо держать еще публичные сервера, такие как web и почту. Описания, приведенные ниже, будут больше относиться именно к этим серверам, чем к сетевому оборудованию. Мне как-то довелось рассказывать медику о работах проводимых при возникновении неисправностей: \\ Я: //Звоним клиенту и выясняем, что происходило во время появления проблемы// \\ Он: //Собираете [[wpru>анамнез]]// \\ Я: //Смотрим на параметры, проводим тесты// \\ Он: //Отправляете на анализы// \\ Я: //Предполагаем причину// \\ Он: //Ставите диагноз// \\ Я: //Приступаем к ремонту// \\ Он: //Назначаете лечение// \\ Короче, мы друг друга поняли :-) \\ //(Правда, неправильный диагноз для нас не является чем-то трагическим, это всего лишь повод поставить другой. Врачи себе таких вольностей позволять не должны)// Ещё довольно часто приходится попадать в ситуации, когда чувствуешь себя монтажником, чинящим балку, на которой сидит. Именно такие ощущения возникают, когда необходимо поменять параметры интерфейса, через который ты подключен к устройству. За годы практики у меня уже набралось много приемов, позволяющих не "потерять" прибор. Но всё равно, рука замирает перед решающим нажатием на кнопку. Ведь цена "потери" -- время, потраченное на выезд к устройству, а оно может измеряться часами и даже сутками. <html><div class="cleaner"> </div></html> ==== Integrated Internet Project ==== Это проект появился при поддержке Института "Открытое Общество". Целью проекта было предоставление выхода в интернет для организаций науки, медицины, образования, культуры и искусства. Я был занят в части этого большого проекта - в так называемом московском проекте. Кроме самой Москвы мы еще занимались техническим обслуживанием Питера. В 1997 году я только начал свою трудовую деятельность, поэтому очень многое было в первый раз. Первый раз я столкнулся с сетевым оборудованием вообще и с оборудованием Cisco в частности. По сути, мы являлись интернет-повайдером с очень маленьким штатом. Технических специалистов было всего двое. И я один из них :-). Соответственно, круг обязанностей был достаточно широк: от обслуживания маршрутизаторов клиентов до поддержания **BGP** для связи с другими провайдерами. Мы являлись **[[wpru>LIR]]-ом**, т.е. занимались распределением IP-адресов выданных [[wpru>RIPE_NCC|RIPE]] для самих себя и своих клиентов. Проект до сих пор является [[http://www.ripe.net/membership/indices/data/ru.iip.html|членом]] RIPE NCC. Кроме того, центральный маршрутизатор находился на ММТС-9 и был подключён к [[wpru>M9-IX]]. И до сих пор [[http://www.msk-ix.ru/members/?org_oid=467&lang=ru|подключен]]. {{ :projects:iipnet-lg.png?88|Мой looking glass}} При установлении пиринговых отношений с другими операторами по BGP очень полезно видеть картину со стороны партнёра: все ли префиксы, анонсируемые нами, он видит, с нужными ли атрибутами. Можно конечно, попросить партнера прислать то, что он видит на своем маршрутизаторе. Но это не особенно удобно и оперативно. Очень полезный инструмент в этом деле - **[[wpru>Loоking glass]]**. Он позволяет видеть, что происходит у партнёра именно в данный момент. Ну и, соответственно, партнёру гораздо удобней, если ты предоставляешь такой looking glass для него. Поэтому я решил написать свой. Он до сих пор [[http://noc.iip.net/lg/|работает]] и, надеюсь, используется. <html><div class="cleaner"></div></html> Большинство организаций было подключено по [[wpru>Frame Relay]], последнюю милю для них обеспечивал Совам. Но ряд научных институтов был подключен к оптоволоконной магистрали. Магистраль представляла собой [[wpru>FDDI]]-кольцо растянутое от центра Москвы до ул. Волгина на Юго-Западе. Называется эта магистраль **ЮМОС (Южная Московская Опорная Сеть)**. Следует отметить, что проект больше известен именно под этим названием (ЮМОС). <html><div class="cleaner"></div></html> {{ :projects:iipnet-map.png?88|Карта проекта}} На сайте проекта размещена [[http://www.iip.net/maps/moscow97/|интерактивная карта]] с нанесенными на нее организациями-клиентами. Собственно для ее подготовки я написал свою первую программу на [[wpru>Perl]]. Из текстового файла с описанием организаций и ряда графических подложек с кусками карты скрипт генерировал необходимый набор HTML-файлов и картинок. Таким образом, при появлении новой организации нужно было только пополнить текстовый файл и запустить скрипт. По нынешним временам, получившаяся карта выглядит довольно убогой. Но в 1997 году я слышал довольно лестные отзывы о самом принципе представления информации. И даже видел карту подобную моей у другого оператора. <html><div class="cleaner"></div></html> В 2001 году Институт "Открытое Общество" стал сворачивать свои программы, и проект ЮМОС целиком перешел в АНО "Наука и Общество". Сотрудники центра управления переехали на территорию [[wpru>ИФП|Института физических проблем им. П. Л. Капицы]]. Расположились мы в двухэтажном особняке, в котором раньше была библиотека и лаборатория Капицы. Я находился под большим впечатлением от этого. Именно в то время я занялся изучением [[wpru>PHP]] и [[wpru>MySQL]]. Естественно, под это нашлась задача нужно было вести базу с данными о клиентах, которых становилось все больше. Примерно за полгода до ухода из ЮМОСа мне удалось подготовить преемника. Правда большáя заслуга в этом принадлежит самому студенту, человек оказался способным (до него не удалось обучить двоих). В любом случае, проект я покидал спокойным за его судьбу. ==== Мотеко ==== Еще до перехода в 2003 году в **Московскую Телекоммуникационную Компанию (Мотеко)** я участвовал в разработке ее web-сайта. В самой компании мы спроектировали несколько сетей для корпоративных клиентов, построили и поддерживали их последующую работу. Составной частью каждого из этих проектов была организация внутренней телефонной связи. Для этого в территориальных отделах были установлены маршрутизаторы Cisco с портами [[wpru>FXS]], а в центральном отделе голосовой шлюз для подключения к офисной АТС по потокам ISDN [[wpru>PRI]]. В качестве протокола сигнализации использовался [[wpru>H.323]], а для централизованного управления планом номеров был установлен [[wpru>гейткипер]]. За состоянием каналов к отделам клиентов круглосуточно следила дежурная смена. Для её работы была создана система мониторинга. Набор скриптов производил периодический опрос каналов и "складывал" результаты в БД MySQL. А данные из БД отображались в web-интерфейсе для дежурной смены. ==== Совтел ==== В течение двух лет я работал ведущим инженером в компании Совтел. Занимался предпродажной подготовкой сетевых проектов и дальнейшим их сопровождением. По большей части мы использовали оборудование Cisco Systems и RAD. В качестве более экономичных шлюзов [[wpru>VoIP]] часто использовали оборудование codian, addpac и audiocodes. Наиболее значимым заказчиком был [[wpru>ЦЭНКИ]]. Именно благодаря этому проекту я побывал в Центре Управления Полётами в Королёве (городе, котором я теперь живу). А кроме того, в этом проекте мне довелось настраивать наиболее удалённые устройства: в Калининграде на судне [[wpru>Космонавт Виктор Пацаев (судно)|"Космонавт Виктор Пацаев"]], на Байконуре, в Уссурийске и Улан-Уде. Требовалось организовать передачу данных, [[wpru>VoIP]] и [[wpru>TDMoIP]]. Ещё одним крупным клиентом был поволжский оператор мобильной связи СМАРТС. Для него мы поставляли и настраивали [[wpru>SDH]]-мультиплексоры. Тут мне несколько пришлось отойти от принципа удалённого администрирования -- приходилось ездить в командировки на пуско-наладочные работы. За то я присутствовал при совершении первого звонка с телефона СМАРТС из самарского метро, который был сделан через наше только что установленное устройство. ==== РИСТЕК ==== В ООО [[http://www.ristec.ru/telecom/|РИСТЕК]] (Распределенные интеллектуальные системы и телекоммуникации) я пришёл в 2005 году. Многие направлениями работы компании совпадают с существовавшими в Мотеко. Да и основной костяк сотрудников перешел из Мотеко. Соответственно, и большинство технических наработок было унаследовано оттуда. Появились и принципиально новые проекты. === Оптоволоконные участки сети === В Москве была построена оптоволоконная сеть, соединяющая офисы клиентов между собой и с ММТС-9, где присутствуют основные операторы связи. Это позволяет легко организовать связь как с отделами по Московской области, так и со структурами клиентов в других регионах. В ряде городов Московской области так же были построены участки волоконной сети. В сети были установлены коммутаторы GigaEthernet. Связь между сегментами сети в разных городах области осуществляется по каналам оператора Центртелеком. Построение оптоволоконной сети позволило обеспечить клиентам более широкие каналы связи и предоставить возможность для новых сервисов, таких как аудио- и видео-конференции, а также системы видео-наблюдения. === Аудио- и видео-конференции === По заказу одного из клиентов была разработана система аудио-конференций. В качестве сервера многоточечных конференций был использован Polycom MGS-50. В качестве абонентских устройств были использованы уже существовавшее устройства VoIP. С 2006 этот клиент проводит регулярные еженедельные селекторные совещания с использованием нашего оборудования. Есть принципиальная возможность организовать не этом же сервере видео-конференции. Для другого клиента была развернута система видео конференций. Был выбран более бюджетный сервер Codian MCU 4200. В качестве абонентских устройств было использовано Tandberg. === Система обработки заявок === По заказу крупного ADSL-оператора Ристек разработал систему обработки заявок. Заявленная проектная мощность - 40 тысяч портов ADSL. Согласитесь, справиться с таким объёмом подключений вручную довольно затруднительно. Архитектура была выбрана следующая: система разбита на модули: * реализующие общесистемные функции, * рабочие места для сотрудников различных подразделений оператора, * отвечающие за синхронизацию данных с существующей биллинговой системой, * автоматический импорт заявок, поданных клиентами через web-портал оператора. Модули взаимодействуют между собой через БД MySQL. Модульность позволила легко разделить разработку между несколькими программистами. Я реализовал системы * разграничения полномочий пользователей -- сотрудников оператора, * учета оборудования, * учета использования ресурсов: портов и ip-адресов. {{ :projects:asoz-zayavka.png?88|Заявка}} {{ :projects:asoz-port.png?88|Занятый порт}} По стечению обстоятельств спустя год после запуска системы в работу я сам стал клиентом данного оператора. Данные по моей заявке можно увидеть на картинках справа. <html><div class="cleaner"> </div></html> Модульность, заложенная в системе, и принцип открытого кода сослужили хорошую службу. Оператор может без нашего участия своими силами поддерживать и развивать систему, чем успешно и занимается. {{ :projects:noc-shema.png?88|Оптические устройства}} {{ :projects:noc-con.png?88|Состояние каналов}} Кроме того, взяв основу и написав новые модули, мы адаптировали систему под собственные нужды -- мониторинг арендованных каналов и состояния собственных сетевых устройств. <html><div class="cleaner"> </div></html> ==== ЮМОС-Телеком ==== Для ЮМОС-Телекома -- дочки "большого" [[start#Integrated Internet Project|ЮМОС]]-а по договору я настраивал роутеры на основе серверов Linux. У первого было 7 интерфейсов FastEthernet (один интегрированный в материнскую плату плюс три двухпортовые карточки). Не долго думая, я назвал его осьминогом или сокращенно osmi. Двухлетний опыт эксплуатации в промышленном режиме показал работоспособность такого решения. BGP, реализованный в пакете [[wpru>quagga]], "держал" две-три "полные таблицы", анонсированные внешними операторами, а также несколько сотен маршрутов пришедших от пиров. Полоса пропускания в пиковых нагрузках достигала 100Мбит/сек, т.е. "упиралась в потолок" FastEthernet-а. При этом ресурсов сервера хватало еще и на биллинговую систему. Второй сервер был построен на смену первому, и был назван наутилусом или сокращенно nau. У него уже не было так много интерфейсов, за то он имел два интегрированных порта GigaEthernet и к ним был подсоединен коммутатор Catalyst. Эти порты работали в режиме tagged, т.е. через них передавались несколько [[wpru>vlan]]. Такая схема позволила настроить несколько логических интерфейсов на каждом физическом порту. И этот роутер успешно работал месяцами без перегрузок. ==== Подготовка дистрибутива Linux ==== Моим знакомым понадобилось устройство, которое позволяет эмулировать задержки свойственные глобальной сети. Они боролись с некими ошибками. Причем эти ошибки у них "на столе" не проявлялись, а возникали только у заказчика на реальной сети, в которой есть каналы с достаточно большой задержкой передачи пакетов. Собственно, готовое решение уже есть: в Linux можно для какого-либо интерфейса приписать исходящей очереди пакетов специальную дисциплину [[http://www.linuxfoundation.org/en/Net:Netem|netem]]. У этой дисциплины есть параметры, позволяющие вносить в передачу пакетов задержки, [[wpru>джиттер|джитерры]] или даже потери. Загвоздка в том, что у знакомых не было в штате специалиста по Linux. Отрывать от основных задач кого-то из своих программистов, чтобы он погрузился в linux, ради единичной потребности особого смысла не было. Поэтому привлекли меня, в качестве внешнего специалиста. Итак, моя задача свелась к следующему: - взять машину с двумя интерфейсами ethernet, - установить на нее подходящий дистрибутив linux, - объединить оба интерфейса в бриджовую группу (это позволит прозрачно установить эту машину в разрыв линии ethernet) - написать web-интерфейс, чтобы этим хозяйством можно было управлять не вдаваясь в тонкости командной строки. Написание web-интерфейсов -- дело для меня привычное, и нужную машину я подготовил для знакомых достаточно быстро. Она позволила им убедиться, что ошибки в их системе возникают именно из-за задержек пакетов и понять как с ними можно справиться. На этом проект не закончился, а только начался. Знакомые озвучили другие необходимые им вещи: * реализовать на той же машине некий фильтр пакетов, * с большой вероятностью им потребуется такую же систему установить на другие машины, поэтому желательно иметь возможность быстро и не вдаваясь в детали ставить на новую машину linux и инсталлировать на нее набор моих программ. Для решения первой задачи было сделано: - написан загружаемый модуль ядра, - к исходникам iptables была добавлена часть, взаимодействующая с модулем ядра, - написан веб-интерфейс. Вторую задачу, как мне показалось, элегантнее всего решить с помощью механизма kickstart, присутствующего в [[wpru>RedHat]]-овских дистрибутивах. Суть его заключается в том, что установщику можно указать текстовый файл, в котором перечисляется, что нужно делать установщику: как разбивать жесткий диск, какие пакеты устанавливать, какие скрипты выполнять до/после установки пакетов и проч. В итоге удалось получить CD, который можно вставить в компьютер, загрузиться с него, нажать две клавиши (для выбора пункта меню) и через 20 минут получить готовое устройство, к которому можно подключиться с помощью браузера и начать использовать. //(Можно было бы сделать и так, чтобы кнопки совсем не нужно было бы нажимать, но это было бы слишком жестоко. Представьте, Вы случайно вставляете этот диск в свой рабочий компьютер, загружаетесь с него и наблюдаете, как форматируется Ваш винчестер. Вместо этого Вам показывается предупреждение о возможности отказаться от установки, если Вы в этом не уверены.)// Для решения второй задачи было сделано: - все мои программы и скрипты были упакованы в пакеты RPM для возможности автоматической установки, - из репозитория Fedora 10 были выбраны свежие версии только необходимых пакетов (полный набор пакетов просто не влез бы на один CD) - подготовлен собственный репозиторий для сохранения на CD, - подготовлен файл kickstart, - подготовлена конфигурация isolinux -- начального загрузчика с CD (именно здесь можно разместить предупреждение о предстоящей установке и сформировать меню позволяющее как принять установку, так и отказаться от нее), - все это сведено в итоговый iso-образ CD. Вуаля! Осталось только прожечь этот образ на CD, и использовать его по назначению. Теоретически можно было бы подготовить LiveCD, но этот метод я попробую в следующий раз.