dump -0f - /dev/mind

Вышел третий номер "Практики функционального программирования"!

2009-12-21T09:00:15Z

Вышел в свет третий выпуск журнала «Практика функционального программирования».

Коллектив авторов поздравляет вас с наступающим Новым Годом! Чтобы вам было, чем занять послепраздничные выходные (и большую часть января :), мы подготовили для вас конкурс, задачи для которого обсуждались тут ранее!

Кроме того, в ~~уникальной цирковой~~ программе: рекурсивные функции тянут себя за хвост, факир прячет уходящие за горизонт фермы memcached под тонким уровнем абстракции, дрессированный верблюд превращается в кучу перьев и 1001 процесс, развенчание полиморфизма и разрезание функциональной парадигмы на части без наркоза.

Перейти к оглавлению номера.

Машина Дильберта

2009-12-20T20:09:35Z

Что такое "машина Тьюринга", знают все (или почти все).

А вот что такое "машина Дильберта"?

Календарик с Дильбертом любезно предоставлен kseva, за что ей большое спасибо от меня и от Максима!

Опять про Google Maps/Latitude и определение местоположения по базовым

2009-12-04T15:40:58Z

Во-первых, спасибо всем большое за поздравления, нам было очень приятно :)

А теперь - вытащу-ка я полезную информацию из комментариев.

Оператор наведения borbelyua прислал полезную ссылку: http://code.google.com/intl/ru/apis/gears/geolocation_network_protocol.html#request

По ней можно ознакомиться с API, которым, по всей видимости, пользуются Google Maps и Google Latitude.

В частности, видно, что:
1)Информация о силе сигнала и timing advance - используется.
2)Используются как данные о базовых GSM/CDMA, так и данные о WiFi AP. Используются одновременно, в одном запросе.
3)Можно передавать данные более чем об одной базовой => используется neighbor list телефона (список сот, прописанных в текущей в качестве "соседей")
4)В запросе можно передавать свои координаты => таким образом можно обновлять/уточнять информацию в их базе
5)В ответе возвращается точность оценки

Собственно, вот и конец всем спорам, я считаю.

Ну, и напоследок - забавное о жизни машин Google, снимающих streetview для Google Maps: http://googlesightseeing.com/maps?tw=772&p=&c=&t=h&hl=en&ll=51.135268,-114.243715&z=16&layer=c&cbll=51.135197,-114.243803&cbp=12,258.6,,1,2.12

Дорос до версии 1.0 :)

2009-11-29T14:06:36Z

ВНЕЗАПНО Олежке исполнился год.

Откуда у Google таблицы трансляции LAC -> GPS coords

2009-11-12T13:45:31Z

У Google есть сервис Latitude, который позволяет определить местоположение телефона даже в том случае, если он не оснащен GPS.

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

Откуда же у Google сведения о том, где установлены базовые? Я раньше писал, что я не верю, что операторы (даже в США) взяли и поделились с Google этой информацией, и скорее всего Google собрал ее самостоятельно. Возможно - с помощью тех пользователей Google Latitude, чьи телефоны оснащены GPS.

А вот еще одно мнение: http://3.rdrail.net/blog/cell-tower-mapping-how-google-did-it/

Краткий пересказ: автор считает, что Google собирал соответствующую информацию в рамках проекта Google StreetView - ведь все равно они ездят (меееедленнно) по всем улицам на машине, оборудованной камерой. Так почему бы при этом не заниматься сбором информации для Latitude?

Я думаю, что хороших способов много не бывает, и сбор, скорее всего, происходил и так, и так.

UPD: Мое мнение по прочим вопросам из комментариев:
1)Подобная локация по WiFi хотспотам возможна и реально используется
2)Считать местоположение можно не по одной camped cell, а по 6 сотам из neighbour list, пересекая (теоретически посчитанные) их области покрытия. Почти наверняка при этом можно добиться лучшей точности
3)Использовать timing advance не получится, т.к. телефон о нем не знает (если я не ошибаюсь)

Кто про что, а я про двудольные графы

2009-11-05T19:03:12Z

Надысь один мой френд написал пост про проверку двудольности графа на Haskell. После чего другой мой френд взял его код и откомментировал. После чего третий мой френд разразился язвительным постом-комментарием на эту тему (именно в комментариях к этому посту есть эпический тред про вывод типов в PHP и иже с ними).

После этого тема была вытащена на Хабр и образцово отхабрена.

Так как весь базар-вокзал - про Haskell, я тоже хочу добавить пару слов.

Я не буду комментировать все, что написано, я скажу про сам алгоритм. Если б мне пришлось бы его реализовывать на Haskell, то я либо нашел бы чужой исходник и перелицевал бы его прачтически дословно. И у меня получилось бы что-то такое (т.к. исходник был бы наверняка на каком-то императивном языке):

import qualified Data.Map as M
import Data.Array
import Control.Monad.State

type Graph = Array Int [Int]

data Color = Red | Blue deriving Eq

isBipartite graph = run $ do

  -- Проверяем, получилось ли "двудольно" раскрасить все компоненты связности графа.
  -- Чтобы не реализовывать отдельно вычисление связных компонет, тупо пытаемся
  -- начать красить со всех узлов подряд - так ни одна компонента связности никуда от
  -- нас не денется
  allTrue [ paint True node Red | node <- indices graph ]
  where

    -- Пытаемся покрасить узел `node' цветом `color'. Если isSeed == True, то мы
    -- пытаемся начать красить одну из компонент связности графа. Если False - то мы
    -- уже вовсю ее красим.
    paint isSeed node color = do

      -- Каков текущий цвет этого узла?
      current <- gets (M.lookup node)
      case current of

        -- Если узел еще не крашен - красим его цветом `color', а все связанные с ним
        -- узлы красим цветом, отличным от `color'. Проверяем, получилось ли раскрасить
        -- без конфликтов.
        Nothing -> do modify (M.insert node color)
                      allTrue [ paint False edge (swap color) | edge <- graph!node ]

        -- Если узел уже покрашен, а мы пытались начать с него раскраску - пропускаем его
        -- Если же нам встретился покрашеный узел в ходе обхода компоненты связности, 
        -- проверим, нет ли конфликта в раскраске
        Just someColor -> if isSeed then return True
                                    else return (color == someColor)

    swap Red  = Blue
    swap Blue = Red

    -- Кому надо, тот и так понял, что тут написано, а остальные над этим не рефлексируют :)
    run = flip evalState M.empty
    allTrue actions = sequence actions >>= return . and

-- Ну, и пару тестов
bipartite = 
  array (0,8) [(0,[1]),(1,[0,2,8]),(2,[1,3]),(3,[2,6]),(4,[5,7]),(5,[4]),(6,[3]),(7,[4,8]),(8,[1,7])]
                
not_bipartite = 
  array (0,8) [(0,[1,2]),(1,[0,2,8]),(2,[1,3]),(3,[2,6]),(4,[5,7]),(5,[4]),(6,[3]),(7,[4,8]),(8,[1,7])]

main = do
  print $ isBipartite bipartite
  print $ isBipartite not_bipartite

Либо я почитал бы Википедию и реализовал бы алгоритм сам, с нуля. Тогда он получился бы в декларативном стиле, но мне бы понадобилась библиотека алгоритмов на графах:

import Data.Map hiding (map)
import Data.Graph.Inductive hiding (empty)

-- Граф двудольный, если после покраски концы всех ребер имеют разные цвета
isBipartite g = all (differentEndColors) (edges g)
  where
    -- Цвет узла хранится в ассоциативном массиве `coloring'
    differentEndColors (n1,n2) = coloring!n1 /= coloring!n2

    {-
     Этот массив создается из списка [(Node, Color)], где Color -
     это Bool. 
     Список получается так: сначала определяем, на каком
     "уровне" (в дереве поиска в ширину) находится тот или иной
     узел, затем превращаем номер уровня в цвет.
    -}
    coloring = fromList $ map level2color nodes2levels

    {-
     Чтобы определить, на каком уровне находится тот или иной узел:
     1)Разбиваем граф на компоненты связности (components)
     2)Берем первую вершину из каждой компоненты (head) и назначаем ей уровень 0
     3)Получившийся список стартовых вершин засовываем в библиотечную функцию `leveln',
       которая вычисляет уровень всех остальных узлов графа
     В результате получаем список [(узел, уровень)]
    -}
    nodes2levels = leveln (zip (map head $ components g) (repeat 0)) g

    -- Если уровень нечетный - будет цвет True, иначе - False
    level2color (node,lvl) = (node, odd lvl)

-- Перевод графа в вид, нужный для библиотеки
-- Data.Graph.Inductive
makeGraph :: [(Int,[Int])] -> Gr () ()
makeGraph g = mkUGraph vs es
  where vs = map fst g
        es = [(n1,n2) |  (n1,es) <- g, n2 <- es]

-- Ну, и пару тестов
bipartite = 
  [(0,[1]),(1,[0,2,8]),(2,[1,3]),(3,[2,6]),(4,[5,7]),(5,[4]),(6,[3]),(7,[4,8]),(8,[1,7])]
                
not_bipartite = 
  [(0,[1,2]),(1,[0,2,8]),(2,[1,3]),(3,[2,6]),(4,[5,7]),(5,[4]),(6,[3]),(7,[4,8]),(8,[1,7])]

main = do
  print $ isBipartite $ makeGraph bipartite
  print $ isBipartite $ makeGraph not_bipartite

(Спасибо lomeo за ценные комментарии и идею поста)

Вот. С монадными трансформерами, как у antilamer - тоже можно, просто я так не пишу.

Мораль придумайте сами.

Языки программирования в условиях, приближенных к боевым

2009-11-03T22:26:25Z

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

Кульминацией этой переписки стало то, что он предложил мне следующее пари: я формулирую простенькую задачу, после чего мы оба реализуем ее - он на С, я - на Haskell. После этого в условие вносятся небольшие коррективы (моделируем поведение требований в реальном мире), а мы вносим коррективы в наши программы. Результаты сравниваются по скорости исполнения, объему потребляемой памяти, количеству строк кода.

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

Моя первая версия активно использовала Data.Generics и библиотечные парсеры на их основе, поэтому выиграла в размере и читаемости кода, но пролетела по объему потребляемой памяти. Впрочем, мой оппонент настолько понадеялся на мощь C, что решил не использовать библиотечный qsort, а реализовать insertion sort самостоятельно. Это самым пагубным образом сказалось на производительности (LOCs - строки кода, память - в мегабайтах, время - в секундах):

	LOCs	MEM max	Runtime, sec
Haskell, v1	72	580	88
C++, v1	861	55	383

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

В результате я тоже решил "срезать углы", и принести красоту кода в жертву скорости. Мой же оппонент взялся за qsort, и к вторые (финальная) версии нашего кода "финишировали" с такими результатами:

	LOCs	MEM max	Runtime, sec
Haskell, v2	169	130	8
C++, v2	950	54	5

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

К чему я все это веду?

Существует классическая статья "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity", написанная в 1994-м году. За 15 лет многое изменилось, и, думается, многим было бы интересно прочитать подобную статью про положение дел сегодня.

В связи с этим ищутся:
1)Условия подходящей задачи (критерии см. ниже)
2)Желающие реализовать ее на Haskell/C+/Ocaml/Java/Scala/C#/... с тем, чтобы ваш код был нещадно сравнен с другими и опубликован для всеобщего обозрения.

Q:Зачем все это делается?
A:На других посмотреть, себя показать. В частности, чтобы люди имели возможность посмотреть на решения на других языках, и составить о них какие-то мнение.

Q:Чем не устраивает The Great Language Shootout?
A:Тем, что там отдается предпочтение "быстрым и грязным" решениям, которые всячески "срезают углы". Во-первых, в таком стиле пишется дай бог чтобы 5% от всех программ, во-вторых, людям, не знающим язык X, строго противопоказано смотреть на решения на языке X в Language Shootout - останется превратное впечатление.

Q:Как будут сравниваться решения, чтобы определить победителя?
A:Никак, т.к. победителей не будет. Будут приведена определенная статистика по всем решениям, без выводов.

Q:Какой тогда стимул участвовать?
A:На других посмотреть, себя показать :)

Какой должна быть задача?
1)Не заточенной под конкретную ОС (т.е. "Реализовать компонент, встраеваемый в Word" или "плагин для libpam" - не катит)
2)Не заточенной под конкретный язык/фреймворк/... (т.е. "получить список сигнатур методов всех объектов указанной сборки .Net" - не катит)
3)Если глубокие знания в предметной области дают решающее преимущество - это fail (т.е. "реализовать DES-CBC" - не катит)
4)Чтобы она не была из категории "мне не нужно, чтобы плац был чистый, а нужно, чтобы вы задолбались" (т.е. "распарсить XLS-файл, не пользуясь библиотеками" - не катит)
5)Задача не должна требовать много времени на реализацию (если это будут человеко-недели - никто за нее не возьмется)

Какой должна быть реализация?
1)Чтобы ее было не стыдно показать другим. В частности, чтобы решение на языке X не заплевали бы как кривое и неидиоматичное другие программисты, знающие язык X.
2)Идеально было бы давать две реализации: первую с ориентиром на "красоту", "образцово-показательность" и легкость поддержки/развития кода (т.е. пишем как пример кода, который будет прилагаться к резюме :), а вторую - "грязную и быструю".
3)Т.к. библиотеки - это неотъемлимая часть силы и популярности языка, библиотеками "общего назначения" (контейнеры, парсинг, ...) пользоваться можно и нужно
4)Но! Решение, которое свелось к исключительно к нахождению и использованию какой-то (узкоспециальной) библиотеки никому не интересно и рассматриваться не будет.

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

Если у вас есть идея подходящией задачи и вы хотите ей поделится - напишите комментарий, а?

Трудное детство, деревянные игрушки :)

2009-10-27T20:26:26Z

Уважаемые френды-москвичи, а кто может купить для меня в московском инет-магазине одну штуковину (~1кг весом) и послать ее мне по почте или с проводником (т.к. найденные инет-магазины ничего никуда за пределы России высылать не хотять)? Деньги от меня up front, естественно - через WM или "быстрым переводом". Комменты скринятся

UPD: тут набежала жена и сказала, что "одна штуковина" и "1 кг" - это очень мало. Оказывается, существуют Грандиозные Планы, о которых я не подозревал :) But not to worry, дело сугубо добровольное, всегда можно отказаться :)

UPD2: Спасибо вам всем большое! Комментов набежало столько, что не успеваю всем ответить. Я тронут, без балды.

Раз-два-три

2009-10-26T08:51:01Z

Старшему сыну исполнилось три года.

Pic-related загадка: Макс иногда приходит ко мне и говорит: "папа! дай, я запущу на компьютере паровозик". Я открываю ему новый xterm (у меня на ноутбуке linux) и он делает ... Как вы думаете, что он делает (без помощи мышки, клавиатурой), чтобы "запустить паровозик"?

Второй номер "Практики функционального программирования"

2009-09-28T09:50:49Z

Вышел второй номер журнала "Практика функционального программирования" - теперь с меньшим количеством теории и большим количеством практики ;)

Авторы статей: _adept_, thesz, gaperton, alexott, _darkus_, dmzlj и Александр Самойлович.

Читаем на сайте: http://fprog.ru/2009/issue2/
Обсуждаем в ЖЖ: http://community.livejournal.com/fprog/3105.html

Новая атака на алгоритмы шифрования GSM - мысли вслух

2009-09-15T20:08:12Z

Намедни известный эксперт в области информационной безопасности Karsten Nohl выступил с "программным заявлением" (см тут: https://har2009.org/program/events/187.en.html). В двух словах суть его сводится к следующему: бюджетные системы для онлайн декодирования A5/1 - не за горами.

Ассоциация GSM выступила с "ответной речью". Суть ее - "уже боимся!".

Я прочел выступление, и у меня появились вопросы и мысли. Которые я озвучу тут.

1. Как правильно пишет сам Nohl, статьи про первые уязвимости в A5/1 появились чуть ли не 15 лет тому назад, но публичной демонстрации взлома A5/1 в условиях реального мира до сих пор не было. По слайдам выступления сложно это утверждать наверняка, но мне кажется, что мнение Карстена в том, что все, кому надо, ломают A5/1 втихаря и никто не делится. Мое мнение другое: чтобы реально слушать разговоры, нужно помимо собственно нахождения уязвимостей в A5/1 решить еще ряд сугубо инженерных проблем, до которым криптографам нету дела, вот они и не делают публичных демонстраций. Решил ли кто-то еще эти проблемы и воплотил ли решение в железе - вопрос открытый (см. ниже).

2. После статьи 2006-го года Эли Баркана сотоварищи не было (насколько мне известно) других работ с публикацией более серьезных уязвимостей в A5/1.

Что же "нарыл" коллектив Баркана? Основной их результат следующий - т.к. в GSM коррекция ошибок идет до шифрования (а надо бы наоборот), возможно определенное уменьшение пространства поиска для подбора Kc и реализация known ciphertext аттаки (т.е. при полностью пассивном прослушивании эфира) за вменяемое время с помощью предварительно вычисленных данных.

Сами авторы статьи говорят, что при приеме без помех для взлома в течении 2 минут требуется 50 терабайт предвычисленных данных. В той же статье (в разделе про A5/2) пишется, что сигнал из эфира всегда идет с помехами, которые "мешают жить" алгоритму подбора ключа. Для A5/2 приведен измененный алгоритм, который способен работать в присутствии помех, но требует вдвое большего объема предвычисленных данных и двукратного увеличения времени на взлом. Для A5/1 указана возможность построения аналогичного алгоритма, но сам он не приведен и влияние помех на объем предвычисленных данных для A5/1 даже не оценено. Будем считать, что и в этом случае нужно увеличить объем предвычисленных данных вдвое.

Кроме того, процесс подбора ключа A5/1 является вероятностным - чем дольше мы слушаем и считаем, тем больше вероятность подобрать Kc. Соответственно, заявленные в статье 2 минуты - это примерное, а не гарантированное время подбора Kc.

Из чтения слайдов Карстена, сайта его проекта и сайта проекта THC я так и не понял, как они "усушили" 50 терабайт (или даже 100, если считать с удвоением) из оригинальной статьи до 2 Tb. Скорее всего, т.к. речь идет о time-memory tradeoff, они используют меньше memory, но больше time, полагаясь на то, что с 2006-го года процессоры стали несколько быстрее :) Было бы неплохо получить какое-то подтверждение этому предположению.

3. Но как же получить данные из эфира? Проект Карстена тут ссылается на THC и проект airprobe. А у них - результаты более чем скромные. Если я все правильно понял, то максимум, что сумели сделать энтузиасты - это при помощи Нокий с прошивкой DHT3 записывать свои собственные разговоры, а потом их ломать. Т.е. дизайна и уж тем более реализации полноценного пишущего сканера GSM-сети у них нет.

А что должен уметь полноценный сканер? Как минимум, разбираться, какие базовые вещают вокруг, на каких частотах, каким операторам они принадлежат, какие телефоны с какими TMSI (temporary IMSI) проявляют вокруг активность. Сканер должен уметь следить за разговором с указанного телефона, корректно обрабатывая переходы на другие частоты и базовые.

Впрочем, если не получится сделать что-то работающее самостоятельно, подобное устройство (пишущий сканер без дешифратора) можно купить за несколько (десятков) килобаксов ;)

4. Получается, чтобы построить прибор с "красной кнопкой", по нажатию на которую мы начинаем слушать "снятый" из эфира разговор по телефону Х, требуется:
а)реализовать часть, которая разбирается с эфиром. В частности, позволяет указать, какой из TMSI соответствует нашему телефону или с помощью активных атак заставить телефоны "обнаружить" свои реальные IMSI и MSISDN (я про подобные способы писал в предыдущих постах)
б)реализовать алгоритм подбора Kc для A5/1, хорошо работающий на реальных данных (с помехами/ошибками, пропусками и т.п.)
в)рассчитать для него rainbow tables
г)объединить все это в законченное работающее решение.

Пока что мне кажется, что Карстен сотоварищи работают над пунктом (в). Причем я лично не думаю, что они рассчитывают rainbow tables для алгоритма, удовлетворяющего требованиям из пункта (б). Скорее всего, это таблицы для алгоритма, работающего на "идеальном шифропотоке" без искажений. По крайней мере, у них на wiki не написано обратного.

Исходя из этого я думаю, что совершенно не зря нет публично известных демонстраций взлома A5/1 - хоть энтузиастами, хоть поставщиками коммерческих решений.

А что думаете вы?

ICFPC'09: результаты

2009-09-14T11:16:08Z

Я ~~слоупок~~ опять все пропустил: уже есть результаты ICFPC'09.

Ваш покорный слуга на 71-м месте из 328 участников. Учитывая все обстоятельства, я доволен.

Полный список результатов лежит тут. Правда, цифры там обманчивы. В таблице приведены баллы, которые участники "выбили" в ходе соревнования на одних и тех же картах. А по окончанию соревнования судьи взяли исходники тех, кто попал в Top-10, и погоняли их у себя на каких-то других картах, которые до этого никто не видел. Финальные места определялись именно результатами вот такого "теста на выживание".

Именно поэтому команда shinh вытеснила с первого места pepsiso, у которой был совершенно, казалось бы, недостижимый отрыв в 300 очков от всех остальных. Жалко, что полные результаты перестановок в первой десятке не выложили :(

Из интересного:
* Победитель писал на C++, второе место - на Java, судейский приз - неизвестно, победитель lighning round - на OCaml.
* Второе место - команда THIRTEEN - из Харькова
* Не написано, почему приз судейских симпатий ушел команде "when i was 4 years old i was maimed by a giant pig", но не исключено, что именно за название :)
* Победу в lightning round-е взял широко известный в узких кругах Алексей Щепин (человек-команда jabber.ru), с чем я его от души и поздравляю :)

Ждем в следующем году схватку между jabber.ru и THIRTEEN за первое место :)

"You have unofficially advanced to Round 2"

2009-09-12T20:52:30Z

Раунд 1А был в 4 часа утра, и я, естественно, его пропустил. В раунде 1B сделал первых две задачи полностью, благо они решались "в лоб", а третью не успел дописать :(

Обидно, она была самой интересной.

Пришло письмо из гугла о том, что %SUBJ%. Непонятно только, почему unofficially

Удивительное рядом :)

2009-09-11T17:05:26Z

Я ожидал, что статьи на mobile-review вызовут комментарии, которые можно будет условно разделить на следующие категории:

"Прочитал. Очень интересно"
"Прочитал. Ничего не понял"
"Прочитал. Нафига про это писать, и так все понятно?!"
"Прочитал. Автор - идиот: ...."

Все вышеперечисленные категории реально присуствуют. Но! Есть достаточно много комметариев вида:

"Прочитал. Статья явно рекламная!"

Шановна редакцiя, я у шоцi. Что ж я там рекламирую-то?

PS
Сами обсуждения:

Кто где был и глобальная корреляция геолокационных данных

2009-09-09T11:44:13Z

Вопрос от malx : "http://jeffjonas.typepad.com/jeff_jonas/2009/08/your-movements-speak-for-themselves-spacetime-travel-data-is-analytic-superfood.html
что скажешь про такое вероятное будущее? :)"

Про будущее не скажу, скажу про текст по указанной ссылке.

Два основных "системных" пробоя в изложении:

Цитата: "Every call, text message, email and data transfer handled by your mobile device creates a transaction with your space-time coordinate (to roughly 60 meters accuracy if there are three cell towers in range)"
Перевод: "Любой звонок, SMS, email или передача данных при помощи мобильного устройства оставляет (в недрах оператора) запись о ваших пространственно-временных координатах (с точностью до 60 метров, если вы находитесь в зоне покрытия трех базовых станций)".
Лажи: 1)Упоминание трех базовых говорит, что автор имеет в виду "триангуляцию по базовым", о которой я уже писал стопятьсот раз
2)В записях учета стоимости (а речь явно о них) как правило остается упоминание о одной базовой. Той, которая начала обслуживать соотв. событие. Если это был звонок, и вы сидели в автомобиле, то, пока вы ездите в зоне обслуживания одного коммутатора (а это очень большая область) никто не будет генерировать доп. информацию о том, на какие базовые переключается ваше обслуживание.

Цитата: "Got a Blackberry? Every few minutes, it sends a heartbeat, creating a transaction whether you are using the phone or not."
Перевод: "Телефоны с Blackberry раз в одну-две минуты посылают 'пинг', о чем остается запись у оператора. Не важно, используете ли вы в это момент телефон по назанчению или нет - это все равно происходит"
Лажа: основным техническим преимуществом Blackberry по сравнению с комбинацией "телефон + почтовый клиент + IMAP-idle или POP pull" является как раз то, что мобильному устройству не надо поллить ящик - по приходу новой почты сервер сделает push. Плюс ко всему, подобное "пингование" ело бы аккумулятор, как свинья помои. Соотвественно, хоть я и не спец в Blackbery, я готов дать зуб, что никакого heartbeat телефоны Blackberry не посылают.

Что интересно, ближе к концу статьи автор говорит, что "если вам удасться найти место на Земле, где на многие мили вокруг есть только одна базовая, и поселиться там, то вы будете в бОльшей безопасности [относительно определения вашего местоположения]". Т.е. мое предположение о том, что автор имеет очень мало инфы о том, какая информация о положении абонента сохраняется и где, подтверждается.

Все прочее, описанное в статье (использование хитромудрых рассчетов для корреляции данных о перемещении людей, выявление клик и кластеров, делание далеко идущих выводов) - теоретически возможно. Но есть одно "но".

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

Но в большей части случаев компании этого не делают. Потому как: 1)сложно; 2)дорого; 3)сложно; 4)дорого; 5)вложения не оправдывают результаты. И мне кажется, что на сегодняшний день потенциальная отдача от подобной аналитики в глобальных масштабах никак не может оправдать затраты на создание соответствующих вычислительных средств. И слова автора о том, что "кто-то уже сейчас может загрузить это все в Amazon S3, запустить кучу процессов на Amazon EC2 и поиметь результат на блюдечке с голубой каемочкой" - это не более, чем фигура речи и сгущение красок.

Стоит ли ноль нескольких миллионов?

2009-09-08T20:51:15Z

Вопрос от crazy_daemon: "Увидел информацию, что с 14 октября начнется переход на европейскую систему нумерации.
И тут увидел следующее:
Ориентировочная стоимость внедрения новой нумерации для одного оператора – десятки млн. гривен.

Ну и собственно вопрос оттуда же:
А откуда у этой суммы ноги растут? т.е. на что должны операторы потратиться при переходе на нули?

Я не буду считать чужие деньги, но я попытаюсь перечислить то, что реально надо сделать при переходе на новую нумерацию:

Переделать все рекламные материалы (бигборды, листовки в магазинах, рекламу по ТВ)
Переделать все продажные материалы (стартовые пакеты и вкладываемые в них книжечки и т.п.)
Отдельно провести информирование абонентов о изменении правил набора через наружную рекламу, SMS-ы, анонсы на разных IVR, операторов в call center
Переписать сообщения на всех автоинформаторах, которые что-то говорят про номер
Придумать и реализовать "защиту от дурака", который будет пытаться набирать по-старому. Как минимум, чтобы его не зачарджили по много килобаксов за минуту
Организовать работу с абонентами, которые придут в фирменные салоны с просьбами помочь с содержимым адресной книги, перенестройкой услуг и т.п.
Внести изменения в процедуры управления номерным планом сети, переделать роутинг, опирающийся на номера (а в мобильной сети полно вещей, которые хотят по номеру телефона выяснить номер HLR-а, например).
Перенастроить все "очевидные" информационные системы, которые хоть как-то анализируют префикс телефонного номера: биллинг, сбор записей учета стоимости, управление услугами, интерконнект, борьба с мошенничеством, разнообразные сервисные платформы, предоставляющие дополнительные услуги (голосовая почта, перевод денег, USSD-запросы на управление услугами и т.п.). Изменения, думаю, будут распадаться на несколько типовых категорий, например: префикс номера где-то анализируется на предмет "свой номер - чужой номер"; префикс номера преобразуется во что-то (название бренда, например); введеный пользователем номер валидируется, и в том числе проверяется его префикс; звонкам на номера с определенным префиксом назначена какая-то цена; префикс номера поставлен в соответствие какой-то другой информации.
Провести аудит всех прочих информационных систем на предмет того, не надо ли вносить в них какие-то изменения.
Если в каких-то информационных системах нельзя произвести соотв. изменения с помощью переконфигурации, и нужны дополнительные разработки - заказать их (т.е. написать спеки, запросить изменения, получить их, протестировать и установить) или сделать какие-то (временные или постоянные) костыли
Прошерстить все внутренние нормативные документы и исправить там места, касающиеся номеров (а таких будет дофига и больше)
Приготовиться провести изменения данных о номерной емкости во всех информационных системах компании, в HLR-ах, в базах сервисных платформ и т.п.
Построить или выделить тестовый фрагмент сети (если его еще нет), на котором отработать все необходимые изменения в core network
С его же помощью протестировать, по возможности, все измененные информационные системы
Разработать (многостраничную) процедуру перехода на новую нумерацию.
Протестировать ее
Разработать процедуру отката процедуры перехода, если вдруг в ходе перехода что-то пойдет не так
Протестировать ее
Скоординироваться с другими операторами на предмет проведения межоператорских тестов (интерконнект, роуминг)
Провести их
Скоординировать кучу народа для проведения собственно перехода (как правило, в ночь на день D)
Провести переход (возможно - несколько раз, если с первого раза что-то не срослось)
В авральном режиме разгрести последствия какой-то фигни, о которой, невзирая на все предосторожности, все забыли, и она "выстрелила" после перехода
Через DMS залить абонентам новые настройки MMS, VoiceMail (если надо) или проинформировать их SMS-ами о том, что это требуется
Принять шквал звонков в callcenter от тех, кто, невзирая на шум в СМИ, все проспал

Фактически, объем работ в худшем случае будет сравним с запуском небольшого мобильного оператора. Потянет ли это на лимон баксов? Вполне может быть.

А в это время в замке у шефа ...

2009-09-08T18:20:44Z

Еще один небольшой апгрейд ЧСВ: серия статей, построенная на базе обобщенного и переработанного материала отсюда и из http://pro-gsm.info начала выходить на http://mobile-review.com:
* http://mobile-review.com/articles/2009/sim-clon.shtml
* http://mobile-review.com/articles/2009/triangulation.shtml
* http://mobile-review.com/articles/2009/eaves-dropping.shtml

Темы, как видите, старые, а контент - новый. Еще пять статей в очереди на публикацию.

Почему плохо ходят SMS-ы?

2009-09-07T20:59:16Z

Отвечаю на вопрос: "Мне часто приходится писать смс в другую страну (из Украины в Белоруссию и обратно), и я замечаю, что иногда (один-два дня в неделю) они доходят очень плохо: нет отчёта о доставке на протяжении часа-двух днём, или смс задерживаются, а потом приходят все кучей.

Также заметил, что новое смс может "спровоцировать" доставку, и все предыдущие будут доставлены вместе с ним.

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

Со звонками проблем нет вообще, всё соединяется сразу, но это дорого и не так удобно.

Если это важно, то в Украине оператор Киевстар, а в Белоруссии Velcom. Впрочем, примерно аналогичная картина и с Билайном у нас - Life у них.

С чем это всё может быть связано? Как найти причину, и кто поможет решить вопрос?"

Попробую ответить.

Я уже когда-то писал о том, как устроены "внутренности" системы доставки SMS - почитать об этом можно тут: http://users.livejournal.com/_adept_/77752.html.

Краткий пересказ:
1)С мобильного телефона (пусть будет Билайн) отсылается SMS. Он попадает на SMSC Билайна.
2)SMSC Билайна смотрит, что получатель у нас - клиент белорусского Life. SMSC контачит базу абонентов (HLR) белорусского Life и спрашивает:"где ошивается такой-то оболтус?". На что HLR отвечает: "ошивается он в зоне нашего коммутатора #13".
3)SMSC Билайна контачит коммутатор #13 белорусского Life и говорит: "доставляй SMS"
4)Коммутатор доставляет SMS. В обратном порядке начинают передаваться подтверждения о доставке.

Если на шаге (2) получен ответ о том, что абонента нет в сети, то SMSC Билайна говорит HLR-у Life: "когда появится, пни меня". После регистрации абонента в сети немедленно срабатывает уведомление и происходит попытка доставки.

Если облом происходит на шаге (4), то SMSC будет повторять доставку в соответствии со своими настройками (как правило, увеличивая паузы между попытками). В процессе SMSC всегда готов принять "встречное предложение" - если HLR Life скажет ему, что теперь уже снова можно пытаться доставлять, то SMSC это и сделает. Впрочем, сбои при доставке SMS "живому" абоненту в работающей сети редко имеют системный характер.

Что же происходит у автора вопроса? Точно утверждать сложно, но самым вероятным предположением выглядит такое: у получателя SMS-ок банально заканчивается место в SMS inbox на телефоне.

При этом происходит следующее: при попытке доставки очередного SMS телефон получателя говорит: "в меня больше не лезет". Информация об этом доставляется SMSC Билайна, который переходит в режим "будем пытаться еще через какое-то время". Кроме того, по стандарту телефон получателя может (насколько я помню, не обязан) после появления места в inbox уведомить HLR своей сети, который, в свою очередь, уведомит все SMSC, которые "подписались" на получение информации об этом событии.

Похоже, что уведомление об очистке inbox либо не генерируется, либо SMSC сети отправителя не информируется об этом событии. Кроме того, иногда абонент просто спит (указано, что проблемы начинаются ночью) и очищает inbox только к утру.

Так как SMSC сети отправителя не получает информации, что уже можно повторять доставку, он делает это сам только по истечении определенного таймаута. Так как речь идет о доставке в чужую сеть, сигнальный траффик тоже может быть платным, и SMSC может быть настроен таким образом, чтобы не пытаться слишком часто - например, не чаще раза в несколько часов.

Допустим, было послано несколько SMS-ов. При доставке первого (второго, третьего, ... N-ного) выяснилось, что inbox полон, и все они стали в очередь на retry. В это время получатель почистил inbox. Дальше происходит одно из двух:
1)Либо приходит еще одна SMS-ка, которая сходу доставляется и запускает процесс доставки все накопленной очереди
2)Проходит несколько часов, одна из SMS-ок доставляется при retry и запускает процесс доставки всей очереди.

ИМХО, очень похоже на описание симптомов из вопроса.

Напоследок хотелось бы добавить пару слов про SMS inbox. Не знаю, как сейчас, а раньше он мог быть только на SIM-карте (т.к. SIM рулит процессом приема SMS-ов) и размер его был достаточно скромным - например, 16 позиций. Конечно, телефоны достаточно быстро научились копировать SMS-ки из памяти SIM-карты в память телефона прозрачным для пользователя образом, но прием SMS-ов все равно происходил в SMS inbox на SIM-карте, используемый как буффер. Кроме того, в SMS inbox на SIM-карте могли помещаться SMS-ки, помеченные пользователем как "saved SMS", "keep on SIM SMS" и т.п. (конкретные слова могут отличаться в зависимости от модели телефона).

Дальше - мои домыслы. Если у человека на телефоне/SIM-карте SMS inbox размером в 16 позиций, и 15 из них заняты сохраненными SMS-ами, то шансы получить "inbox full" при активной переписке по SMS достаточно велики. Если после этого не отправляется уведомление о появлении места в inbox (а оно появляется, когда телефон сам копирует SMS из inbox в свою память), то может возникать спонтанное "залипание" SMS-диалога. Впрочем, я не дам зуб, что этот сценарий реально может реализоваться в реальной жизни.

PS
Disclaimer. Я не настоящий сварщик, я просто ~~нашел на стройке маску~~ много читал про то, как устроен SMSC. Я никогда их не настраивал и не эксплуатировал лично, хотя и много общался с теми, кто это делает. Я знаю, что меня читают люди, у которых есть непосредственный опыт борьбы с SMSC - поругайте версию, а?

UPD
Даже если у вас телефон, в который влазит 100500 тыщь SMS, прием их все равно ведется в SMS inbox, который находится на SIM-карте, а телефон непосредственно после приема вычитывает их оттуда и размещает в своей необъятной памяти.

UPD2
Еще одна реалистичная версия из комментария magicprinc:
"1) У MSC есть ограничение на количество алертов и вам его не достается т.е. абонент появляется в сети, а ваш смсц не уведомляют - поэтому он пробует через некоторое время сам по retry timeout
2) количество узлов сети растет, а квалификация сотрудников падает - где-то что-то недопрописано (маршруты, разрешения)"

UPD3
От qwe13: "Хех, все совсем забыли про GPRS. Думаю не у многих операторов есть Gs. Как следствие при активной пердачи данных over GPRS абонент не отвечает на пейджинг через "CS". По окончанию передачи GPRS данных абонент ничего не знает о том, что его ждут смски, как врочем VLR тоже не знает, что абонент появился в сети.

Итого смски доходят тогда, когда абонента позвонит/отправит sms или когда входящая смска поймает его не за активной пердачей данных."

99 баллов :)

2009-09-05T18:06:05Z

Прошел квалификацию, выбил 99 из 99 баллов.

Что приятно - во всех задачах сдавал самую первую заработавшую версию кода, в том числе и для large set. Впрочем, это скорее везение или уровень задач.

Google Code Jam'09 - Qualification Round

2009-09-03T13:19:34Z

Кстати, до конца квалификационного раунда Google Code Jam'09 осталось 11 часов. Учитывая, что задачки там - часа на полтора в общей сложности, еще не поздно зарегистрироваться и поучаствовать. http://code.google.com/codejam

PS: если кто участвует: скажите, какой у вас там ник

Он сказал: "поехали!"

2009-08-17T19:02:14Z

Он - это пресс-релиз. На самом деле, там еще есть пару мелких углов, но вписывать прибавку к EXP и ЧСВ можно уже сейчас. Я там собирал требования, писал кучи документов, мигрировал данные и интегрировал все добро в одну кучу. ~~Вот какой я молодец~~

Впрочем, не обошлось без казусов. Некие бравые ребята написали на PL/SQL пакетик процедур, и, натурально, вставили его в Oracle. Другие бравые ребята взяли программу на C#.Net и давай оттуда эти процедуры использовать.

В тестовом окружении (Oracle 8.1.7) - все шикарно. В промышленном (Oracle 9i) - не выходит каменный цветок. Лишь только пытаешься вызвать какую-то процедуру - Оракл тут же говорит ORA-03113, end-of-file on communication channel. И закрывает соединение со своей стороны.

При этом с того же самого компьютера можно подключиться к базе при помощи sqlplus, вызвать искомую процедуру и получить результат. Без всяких ошибок. Хоть раз, хоть десять.

Разработчики на PL/SQL, естественно, тут же воспряли духом - ага, баг не у нас, оказывается! Только толку от этого знания немного - надо же, чтобы в конце-концов все заработало и в приложении на C#.Net.

Разработчики на C# говорят: это все потому, что мы ходим через ODBC. Однако фиг - утилита ODBC Test, написанная (судя по виду GUI) еще во времена Windows 3.1, замечательным образом вызывает процедуры через ODBC.

Тогда разработчики на C# говорят: это все потому, что мы все переписали и теперь работаем через OleDb. Надо поставить ораклового клиента и использовать ODP.NET оттуда. Поставили. Однако фиг - как падало, так и падает. Причем, только с Oracle 9i - с 8.1.7 по-прежнему все хорошо.

Тогда разработчики на C# говорят: это у вас фиговый Оракл. Но их посылают в сад, так как "у меня нет для вас другого Оракла, товарищ Жуков".

Параллельно все участники процесса насилуют Google в поисках других товарищей по несчастью. Классик говорил: "если любишь заглядывать в бездну, помни, что бездна может заглянуть в тебя". Так и происходит: гугл приносит мешок рассказов о том, как по всему земному шару люди бьются лбом об стену с ORA-03113.

Типичные истории звучат примерно так: "Мы тут написали софтину на C#.NET, которая ходит в оракл. С версией 9i и ODP 9.0.1.3.1 все было хоршо, но потом мы обновили ODP до 9.0.1.3.3 и началось - ORA-03113 через пол-часа работы. Мы два месяца плясали с отладчиками, и поняли: у нас на клиентской стороне connection pool, а Оракл со своей стороны временами закрывает соединения по тайм-ауту. В пуле они не инвалидируются, и когда такое соединение выбирается для выполнения запроса, возникает ORA-03113. Мы не можем убрать пул (все тормозит) и не можем убрать отключение по тайм-ауту (требование безопасности). Более того - мы откатили ODP, но проблема осталась! Помогите!". Читаешь, и понимаешь, что у нас еще не все так плохо :)

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

В конце-концов разработчики на C# говорят: "Мы сдаемся! К вам едет "мистер Вульф, который решает пробемы" (Криминальное чтиво).". Приезжает человек, который занимается исключительно troubleshooting-ом разной неведаной фигни.

Человек целый день колдует с компилятором C# и кучей разных библиотек и в конце-концов говорит: "я не знаю, что бы это значило, но факт таков - если я до вызова процедуры сделаю хотя бы один select, то все работает хорошо". Проверяем - натурально, так оно и есть. Может, дело в каких-то миллисекундных паузах? Нет, расставленные по коду паузы не помогают.

Пляски с бубном продолжаются еще день, но без особого результата. В конце-концов принимается волевое решение о том, что код на C# должен после открытия соединения сделать "select table_name from all_tables where owner=current_user" и вычитать первый элемент рекордсета.

И все начинает работать без сучка и задоринки. Мораль придумайте сами.

SmartSIM, TurboSIM, YesSIM и другие устройства для "разлочки" телефонов

2009-08-06T08:45:14Z

Отвечаю на вопрос из пункта приема вопросов: "В интернете обильно продаются всяческие "i-SmartSim SIM Card Unlock Attachment for Nokia and Most Other Cell Phones", стоят от 5 USD. Обычно выглядит как плёночка с чипом, вставляемая между симкой и телефоном. Знакомый мой одну такую купил, и говорит, что в самом деле смог использовать привязанный iPhone с SIMкой другого оператора.
Как это может работать?"

Поиск по названию этих продуктов в основном выдает либо сайты производителей, либо тонны форумов с сообщениями вида: "а на телефоне X с симкой Y будет работать или нет?". Описания принципов работы таким образом найти не получилось.

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

Итак, что же из себя представляют волшебные средства для unlock-а телефонов? Это тонкая (~0,7 мм) печатная плата с микросхемкой, подкладываемая под вашу SIM-карту. Чтобы такой "бутерброд" влез в держатель для SIM-карты, приходится подрезать вашу SIM-карту или вырезать в ней дырку (как показано на рисунке справа), в которую войдет микросхема.

В инструкции по эксплуатации подобный девайсов есть два любопытных момента:
1)Требуется, чтобы ваша сим-карта до этого была хоть раз вставлена в телефон и зарегистрировалась в нужной вам сети. Вынуть сим-карту из упаковки, подложить "анлокер" и включить телефон нельзя - телефон не зарегистрируется в сети.
2)Иногда (как утверждают производители - не слишком часто) после потери сети телефон не будет в ней регистрироваться заново. Тогда надо вынуть симку и анлокер, засунуть симку в другой аппарат, зарегистрироваться в сети, и вернуть симку на место.

Похоже, тут и есть ключ к разгадке. Берем GSM 11.11 "Specification of the Subscriber Identity Module -
Mobile Equipment (SIM - ME) interface" и читаем (фигурно порезано и откомментировано мной. Сокращение "ME" - это телефон, mobile equipment):

"11.2.1 SIM initialization
After SIM activation[...], if the CHV1 verification procedure (т.е. проверка PIN-кода) is performed successfully, the ME then runs the SIM Phase request procedure.
For a SIM requiring PROFILE DOWNLOAD, then the ME shall perform the PROFILE DOWNLOAD procedure in accordance with TS 11.14 [27]. [...] then the SIM is able to allow the REHABILITATE command to rehabilitate EF_IMSI and EF_LOCI.
[..]
For a SIM of Phase 2 or greater, GSM operation shall only start if one of the two following conditions is fulfilled:
‑ if EF_IMSI and EF_LOCI are not invalidated, the GSM operation shall start immediately;
‑ if EF_IMSI and EF_LOCI are invalidated, the ME rehabilitates these two EFs.
[..]
then GSM operation shall start."

Тут есть несколько важных для нас моментов: если в телефоне установлена "модная" и современная SIM-карта, то сразу после проверки PIN-кода телефон должен сделать "PROFILE DOWNLOAD" и доложить SIM-карте о своих возможностях (размер экрана, поддержка доп. услуг и т.п.), а SIM-карта, в свою очередь, рассказывает телефону о своих возможностях (в соответствии со стандартом GSM 11.14). В частности, SIM-карта может сказать, что она умеет выдавать нотификации о том, что какая-то важная информация, хранящаяся на SIM-карте, изменилась. Запомним это.
Далее, EF_IMSI and EF_LOCI - это elementary file-ы (т.е. области памяти) в SIM-карте, хранящие информацию о IMSI и последнем известном location телефона в сети.

Получается, что анлокер работает примерно таким образом:
Телефон после включения делает запрос PIN-кода, передает его SIM-карте и начинает процедуру "SIM Initialization". Телефон запрашивает содержимое EF_IMSI, чтобы проверить, не invalidated ли оно. Как я понимаю, где-то в этот момент в firmware телефона отрабатывают процедуры "залочки", проверяющие, не сунули ли в телефон "левый" SIM. Анлокер, который принимает все запросы от телефона, не передает их оригинальной SIM-карте, а отвечает вместо нее, возвращая телефону "левый" IMSI, принадлежащий нужному оператору - тому, на которого залочен телефон.

Когда телефон добирается до фазы "Location Information request", анлокер перестает вмешиваться в работу телефона и SIM-карты, и в эфир уходит реальный IMSI, хранящийся на реальной SIM-карте, вставленой за "анлокером".

Я не уверен, не съедут ли у телефона мозги от того, что с какого-то момента SIM-карта начнет отдавать другой IMSI. Впрочем, в GSM 11.14 есть лазейка (раздел 6.4.7.1, "EF_IMSI changing procedure"): SIM-карта с SIM Toolkit может послать телефону уведомление о том, что ее IMSI изменился (например, в результате over-the-air обновления конфигурации SIM-карты со стороны оператора), и телефон должен принять это к сведению, переспросить новое значение IMSI и без перерегистрации в сети работать дальше.

Возможно, анлокер использует эту функцию для того, чтобы пройти включение телефона и инициализацию SIM-а с одним значением IMSI, а затем поменять его на другое.

В простых моделях анлокеров есть настройка под названием "IMSI Patch count", которую рекомендуют устанавливать в значение "1" или "2". Подозреваю, это кол-во начальных обращений к EF_IMS, перехватываемых анлокером, в ходе которых он отвечает за SIM-карту, подставляя нужное значение IMSI.

Остается один вопрос - откуда анлокер узнает, какое значение IMSI надо дать телефону, чтобы тот поверил, что в нем стоит "родная" SIM-карта? Некоторые анлокеры используют "универсальные" значения MCC=001, MNC=01, которые по стандартам GSM являются аналогом сегментов 127.0.0.*, 10.0.* и т.п. из адресного пространства TCP/IP и используются в тестовых сетях. По стандарту любой телефон должен без лишних вопросов принять SIM-карту с такими кодами страны и сети. Другие анлокеры требуют один раз вставить в телефон SIM-карту оператора, на которого он залочен, считывают с нее IMSI и используют в будущем. Наконец, есть анлокеры, которые позволяют с помощью программатора задать коды MCC и MNC, которые будут использоваться.

PS
Кроме того, я обновил предпоследний пост про "псевдо-базовые" и их функции.

Обнаружение реальных IMSI и прослушивание переговоров при помощи "виртуальных базовых" - материалы.

2009-07-24T17:18:32Z

Некоторе время тому назад у меня был пост про "виртуальные базовые станции" (http://users.livejournal.com/_adept_/90195.html) и их возможности.

И тут мне ВНЕЗАПНО попались на глаза любопытные материалы по этому поводу:

Обзорное описание принципов работы Rohde & Schwarz RA 900: http://www.crypto.ruhr-uni-bochum.de/imperia/md/content/seminare/itsss07/imsi_catcher.pdf
Материалы судебного разбирательства по патентным правам, обсуждающие детали реализации подобных устройств: http://www.martinhowe.co.uk/pubs/legal/mmivcellxion_judgment_11march2009.doc

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

Рад, что я по всем основным пунктам не ошибся :)

UPD: Короткое резюме своими словами.
По словам производителя, основное назначение устройства - выяснить IMSI/IME телефона, про который известно только то, что он "где-то рядом". Т.е. мы знаем, что вот в этом загороднем доме сидит "подозреваемый" и у него есть телефон, но какой у него IMEI и что за SIM-карта в него вставлена, мы не в курсе.

Подогнав "псевдо-базовую", можно с большой вероятностью добиться того, чтобы все телефоны вокруг всделали location update через нашу "псевдо-базовую". В результате мы получим информацию о IMSI и IMEI всех телефонов вокруг. Если получится отсеять все "левые" - то останется IMSI нужного телефона. Теперь можно идти к оператору и ставить его на прослушку при помощи СОРМ.

Про перехват звонков написано ровно то, что было у меня в после: можно перехватить исходящие звонки, входящие - нельзя. Для перехвата исходящих звонков необходимо дать с "псевдо-базовой" команду на отключение шифрования на трубке подозреваемого. Кроме этого, все прочие товарищи в зоне покрытия псевдо-базовой в этом случае будут сидеть без связи вообще. Т.к. все это легко "спалить", рекомендуется для прослушивания использовать СОРМ и не выделываться.

Вот, вкратце, и все.

Практика функционального программирования

2009-07-22T14:26:35Z

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

http://fprog.ru/2009/issue1/.

Организатор процесса - lionet. Авторы статей: thesz, _darkus_, antilamer, kurilka и alexott.

Официальный анонс:

Первый номер журнала посвящён погружению в предмет функционального программирования. Вводные статьи Сергея Зефирова «Лень бояться» и Романа Душкина «Функции и функциональный подход» затрагивают философию парадигм программирования. Более практически направленная часть журнала представлена статьёй Евгения Кирпичёва «Изменяемое состояние: опасности и борьба с ними», классифицирующей типы проблем, возникающих при небрежном использовании сущностей с изменяемым состоянием, и следующей за ней статьёй Дмитрия Астапова «Давно не брал я в руки шашек», на протяжении нескольких страниц раскрывающей подход проектирования «сверху вниз» на подробном примере написания игры в шашки на языке Haskell. Статья Дэна Пипони «Моноиды в Haskell и их использование» в переводе Кирилла Заборского простым языком обьясняет практическое применение моноидов для создания элегантных полиморфных алгоритмов. Номер завершается внушительным «Обзором литературы о функциональном программировании» Алексея Отта, содержащим множество ссылок на русскоязычную и англоязычную литературу по разным языкам и аспектам декларативного программирования.

ICFPC-2009: Таких не берут в космонавты!

2009-06-29T23:00:16Z

Имя команды: li-monad (спасибо aleksey/jabber.ru за идею)
Состав: я, endless-world, iakovz, при участии blancus.
Итоговый бал: 2234.7171 (12 problems solved)

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

Как я уже писал, в этом году я перепутал июнь с июлем, и чуть было не пропустил ICFPC вообще. О том, чтобы собирать команду, не могло быть и речи - на это просто не было ни календарного, ни свободного времени. В результате, в последние два дня перед соревнованием я попытался найти команду, к которой можно было присоединиться, но все места уже были заняты.

В ходе моих поисков на #icfp-contest в последний день, буквально за 6 часов до начала, меня законтачили два человека и предложили объединится в импровизированную команду. Я согласился, тем более, что вероятно было участие еще пары англоязычных персонажей из haskell community. Забегая наперед, с сожалением констатирую, что из этой попытки ничего особо хорошего не вышло, т.к. командного взаимодействия у нас не получилось, и команда буквально развалилась на ходу еще до конца первых суток. Строить общие планы мои соратники по команде не спешили, чем планируют занимаются - не говорили, а в середине второго дня iakovz вообще пропал, оставив вместо себя полезную ссылку на книгу "Orbital Mechanicas" и приведенного в командную конференцию математика blancus, который честно пытался нам помочь :)

Впочем, обо всем по порядку.

Начатая в прошлом году космическая тема успешно была продолжена и в этом. Если в прошлом году надо было рулить марсоходом, то в этом году нужно было пилотировать спутник.

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

Перевести спутник, движущийся по круговой орбите вокруг центрального тела (Земли), на круговую орбиту с другим радиусом
Произвести "стыковку" с другим спутником, движущимся по круговой орбите
Произвести "стыковку", но при условии, что начальная орбита управляемого спутника и спутника-цели - это не круги, а эллипсы
Пролететь в радиусе 1 км от 11 спутников, движущихся по произвольным орбитам, дозаправляясь топливом на орбитальной заправочной станции и учитывая влияние не только Земли, но и Луны

Программа управления спутником состояла из команд по включению двигателя в определенные моменты времени, которое приводила к мгновенному изменению скорости спутника. Эту программу можно было рассчитывать на листике в клеточку, считать в специализированном ПО вроде MATLAB или Mathematica, или генерировать програмным путем. Для проверки корректности рассчетом можно было скормить свою программу в предоставленный организаторами симулятор движения небесных тел и убедиться, что спутник действительно прилетает куда надо.

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

День первый, старт соревнования в 21:00 EEST 26.06

Мы в течении получаса читали задание, а потом собрались в jabber, чтобы его обсудить. Выяснилось, что понимаем мы его примерно одинаково. После этого мы подключились к gobby и совместно набросали высокоуровневый дизайн решения. Где-то в 23:00 все, кроме меня, отвалились спать, не оставив никаких вещественных результатов. Endless-world сказал, что он пишет VM, и завершит ее завтра с утра. Я написал декодирование байт-кода от организаторов в вид, пригодный для потребления виртуальной машиной и набросал код, который объединяет еще не написанные модули - декодер байт-кодов, VM, поиск решений предложенных задач, формирователь файла с решениями и т.п. - и тоже отправился спать

День второй, 27.06

Организаторы приложили к условию задачи ссылку на страницу на wikipedia с описанием одного из способов решения первой задачи. Казалось бы - бери, кодируй и запускай. Однако, быстро решить первую задачу не получилось. Хотя первая версия VM была готова еще в 10:00, нормальной запустить ее удалось только в 13:40. Мешали как баги, допущенные нами в реализации, так и баги, допущенные организаторами в спецификации. Кроме того, в библиотеке, которую я использовал для побитового декодирования данных, обнаружился мерзкий баг, который периодически приводил к потере данных. Как известно, эффект от независимых багов не складывается, а умножается, что и привело к такой потере темпа.

Еще час был потерян из-за того, что все константы, кроме одной, были указаны в условии в шестнадцатеричном виде. Мы этого при беглом чтении не заметили, и указывали номер задачи в виде 0x1001 вместо 1001. К 15:00 мы с endless-world независимо друг от друга реализовали две версии решателя, вычисляющего параметры Гомановского перехода на другую круговую орбиту, и выяснили, что мы совсем забыли с институтских времен и физику, и математику, и тригонометрию. Разнообразные досадные ошибки (забыли домножить в нужном месте на массу Земли; забыли, как рассчитать вектор, перпендикулярный к данному; ...) привели к тому, что в 17:00 спутник у нас уже летал, но в цель попасть никак не мог.

Перепробовав несколько вариантов расчета перпендикуляра, "смотрящего" в нужную нам сторону (да-да, и нечего смеяться), пересчитав несколько раз формулы из wikipedia по найденной умной книге и оптимизировав VM, чтобы она не отжирала память при работе, мы в конце-концов получили в 19:00 код, решающий первую задачу, для всех четырех вариантов известных старторвых условий.

Ура! Получается, что мы еще успеваем сдать какие-то результаты для участия в т.н. lightning round - соревновании по результатам, полученным в течении первых суток. Но не тут-то было - отосланные организаторам программы управления были проверены и получили оценку "CRASHED!"

Возможных причин было несколько: неправильный формат файла с результатами, спутник врезался в Землю или спутник истратил в ходе маневров все топливо. Т.к. я был уверен, что летаем мы правильно и топливо экономим, я принялся сличать генерируемый нами файл с описанием формата в спецификации. Вроде бы все делаем правильно, а результат не засчитывают - ну, хоть убейся. В конце-концов я смирился с тем, что в формате файла ошибок у нас нет. Получается, мы плохо управляем спутником?

Как выяснилось - мы плохо прочитали и поняли условие задачи. Нам казалось, что если в программе записано "в момент времени T подать имульс V в направлении a", то двигатели включатся и выключатся. А по спецификации получалось, что они включатся и будут работать до тех пор, пока в программе не встретится команда "в момент времени T' подать импульс величиной 0". Соответственно, по мнению организаторов все наши программы врубали газ на полную и летели, куда глаза глядят, вплоть до исчерпания запасов топлива.

К сожалению, осознание этого факта пришло ко мне уже после окончания lightning round-а. Первые наши результаты были приняты уже 28-го числа, сразу после полуночи.

День третий, 28.06

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

Endless-world прочел об этом в блоге организаторов и реализовал хак, который сжигает остатки топлива после выхода на целевую орбиту, и мы получили за первую задачу 382 балла из 400 возможных!

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

Кроме этого, в коде решателя первой задачи (который я хотел переиспользовать для решения второй задачи) нашлись два бага, которые компенсировали друг друга. Со скрипом и проблемами, с многочисленными правками физических рассчетов, к 16:00 появилась версия решения, которая пыталась выполнить phasign -- тот самый маневр по догонянию спутника-цели.

Задание считалось решенным, если наш спутник находился в радиусе километра от цели в течении 900 секунд и при этом не пользовался двигателями. Наше решени замечательно разгонялось, но тормозить у него получалось из рук вон плохо - наш спутник не мог вернуться обратно на круговую орбиту, и быстро удалялся от цели.

Попытки сделать какой-то "подруливатель" успехом не увенчались - становилось только хуже. Во второй половине дня я плюнул, взял Mathematica и самостоятельно вывел решение задачи phasing-а с нуля. Результат получился выше всяких похвал - маневр завершался в пределах +-50 метров от цели, и в течении 900 секунд мы отлетали максимум метров на 100-200. Вторая задача пошла в зачет :)

Мы не писали какого-то отдельного специального визуализатора - наша VM выводила отладочный лог с координатами нашего и целевого спутников на каждом шаге, а я использовал gnuplot для рисования красивых по этому логу:

На первом графике нарисованы орбиты. Видно, как наш спутник стартует почти из центра целевой (зеленой) орбиты, выходит на нее по витку эллипса и сразу переходит на эллиптическую орбиту для того, чтобы догнать цель. В момент выхода на целевую орбиту цель находится "за" нами (по направлению вращения), поэтому наш спутник переходит на орбиту большей длины, рассчитанную так, чтобы по завершению одного оборота мы и цель оказались в одной точке. В этот момент выполняется коррекция курса и наш спутник возвращается на целевую (зеленую) орбиту в 50 метрах от цели.

На втором графике видно, как менялось расстояние до цели (синяя кривая) и расстояние от нашего спутника до Земли (красная кривая) с течением времени.

День третий, 29.06

В общем чат-логе за этот день нет ни одной строчки - все куда-то окончательно разбежались :(

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

К сожалению, все доступные мне источники знаний, как сговорившись, рассказывали о том, как рассчитать параметры орбиты по двум наблюдениям летящего тела - т.е. нам известны только два расстояния от летящего тела до земли и угол между векторами наблюдения. Это так называемая задача Ламберта. Она не может быть решена в общем виде аналитически, требуется составлять и решать численными методами дифференциальные уравнения. Я потратил пол-дня, пытаясь реализовать искомое, но безуспешно. К середине дня мною был найден в сети документ, описывающий значительно более простой метод Гиббса, позволяющий вычислить в аналитическом виде параметры орбиты по трем наблюдениям.

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

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

Отдельно хотелось бы поблагодарить любимую yulanta за предоставленную возможность предаваться сомнительным развлечениям :)

Официальный scoreboard, по состоянию за 5 часов до окончания соревнования

И, наконец, немного статистики и всяких фактов
Объем кода: 1077 строк (из них 100 - VM, и 100 - базовые функции для физических рассчетов), язык - Haskell
Скорость работы VM: ~10 секунд на любой сценарий задачи 1
Кол-во commit-ов в репозиторий: 170 (151 - я, 14 - endless-world, 5 - iakovz)
Кол-во найденных в сети и просмотренных книг по орбитальной механике: 15
Из них полезных: 3
Кол-во памяти, потребляемой первой версией VM: от 400 до 3000 Мб, в зависимости от сценария (из-за неудачного design decision сборщик мусора не мог собрать старые версии состояния VM)
Кол-во памяти, потребляемой VM после оптимизации: от 5 до 20 мб

Финальная версия кода
http://adept.homeunix.net/icfpc2009

Отчеты и репозитории других команд (список будет пополняться)