vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

Заглянуть вперед: какими будут приложения 12

Дата публикации: 11.07.2011
Количество просмотров: 12036

Говорят, «дорога в ад выстлана благими намерениями». В этом отношении сразу вспоминается история середины 2009 года. После выпуска Apple новой прошивки для iPhone, где для экономии заряда аккумулятора включили функцию «быстрого покоя», сети 3G некоторых операторов оказались «наводнены» сигнальными сообщениями. Стремясь перейти в неактивный режим, iPhone запрашивал RNC (контролер базовых станций) о прекращении соединения и высвобождении сигнальных каналов. Устройство преждевременно просило разъединить, а затем запрашивало обратное соединение с сетью. Как заявили в AT&T, в крупных городах, таких как  Нью-Йорк и Сан-Франциско, работа 3G сети была нарушена.

Вероятно, о чем-то подобном в начале 2010 года заявили и в T-Mobile, приведя в пример некое (не указанное) приложение IM (Instant Messenger) для Android, где часто открывались и закрывались соединения. Пока приложение тестировалось в окружении Wi-Fi, проблем не было. Однако в сети 3G, приложение вызвало тяжелые перегрузки на некоторых (опять неуказанных) узлах, так как трафик сигнальных сообщений значительно увеличился. Впрочем, ради справедливости надо сказать, что заявление от T-Mobile, как собственно и AT&T, прозвучало на фоне борьбы вокруг «сетевого нейтралитета».

Тем не менее, несмотря на шумиху вокруг «как передавать биты», важность правильной разработки приложений, которые будут работать в мобильной сети, все-таки трудно переоценить. Показанные выше примеры – яркое тому доказательство. Но сейчас говоря о конвергенции мобильной и проводной связи, о совмещении технологий доступа на уровне технологий, сервисов, о приложениях часто просто забывают. Недавно целый ряд компаний из мира высоких технологий, Amazon, Google и Apple, догоняя один другого, вывели на рынок свои музыкальные сервисы, названные «облачными». И суть не в том, что в них обыгрывается, теперь и со стороны частного пользователя, раздутая маркетинговая концепция.

Нам важно, что трансляция аудио потоков наглядно показывает пример приложения, когда его работа перестает зависеть от типа сети, мобильной или проводной, в которой ведется сетевой обмен. Надо понимать, что таких приложений будет все больше и больше. Ведь интернет, как заверяют в Google и Mobile Marketing Association (MMA), на мобильном устройстве быстро становится необходим пользователю так же, как и на ПК. По сравнению с сетями 2G/GSM и первых версий 3G/UMTS (R99), в сетях HSPA / HSPA+, не говоря уже о LTE, где пропускная способность возросла, а задержки в передаче пакетов уменьшились, - мобильный широкополосный доступ по своим параметрам «встал» недалеко от проводного.

Тест 3G: Предсказуемые результаты (2Q 2011 года, Москва и Московская область), Mobile-review

Правда, здесь возникает интересный момент. Ведь различия между сетями, проводными и мобильными, даже взяв в пример LTE, несмотря на общую основу, где все «крутиться» вокруг IP, - есть, и они значительны. И дело здесь не только в том, что емкость мобильной сети, ограниченная диапазоном частот, спектральной эффективностью стандарта и размером соты, конечна и легче подвергается перегрузкам. Есть и другие нюансы. Вот и интересно попробовать ответить на вопросы, и если не на все, то хотя бы на некоторые, основные: какие еще нюансы надо учесть при разработке приложений, подразумевая, что работать они будут и в мобильных сетях?

Во-первых, как видно из приведенных примеров с AT&T и T-Mobile, радиочастотная среда – это, по сути, общая среда, где работают и другие приложения или устройства. Следует избегать агрессивной или нестандартной модели поведения приложений. Когда в передаче пакетов возникают потери, необходимо отложить передачу или дождаться ответа. Если приложение будет пытаться «протолкнуть» свои данные, это может усугубить причины отказа и сказаться на работе всей сети в целом или какого-либо ее участка.

Во-вторых, параметры передачи в мобильной связи нестабильны и сильно зависят от доступных радио и сетевых ресурсов. Даже в пределах одной соты при перемещении терминала пропускная способность и задержки в сети LTE могут быстро изменяться, в зависимости от соотношения сигнал/шум и соответственно выбранной для потока данных в MIMO-канале по алгоритму PARC (Per-Antenna Rate Control) схемы кодирования (вид модуляции, скорость кодирования и числа расширяющих кодов). Чем дальше от базовой станции и ближе к краю соты, тем хуже соотношение сигнал/шум, а значит, будет применена менее требовательная к параметрам схема и тем скорость передачи будет меньше.

Вдобавок, в то время как LTE обеспечивает высокие скорости передачи и низкую задержку, в ближайшее время его покрытие будет носить «очаговый» характер и сосуществовать с сетями 3G, или даже 2G. Тем более у нас в России надеяться на плотное покрытие сетями 3G с HSPA+ от «большой тройки» (Вымпелком, МТС и Мегафон) явно в ближайшем будущем не приходится. Выходя за пределы сети LTE или HSPA+ (если терминал многорежимный), параметры доступа изменятся, и хорошо, если принимающей сетью будет EDGE, а не вообще только GPRS, без «всяких» там надстроек.

При этом при переходе, хэндовере, из одной сети в другую возможно большая задержка, связанная с передачей соединения. К примеру, при переходе от LTE к CDMA, задержки бывают и до пяти секунд (!), в зависимости от того, работают ли обе сети в одном диапазоне частот. Кстати, обратный переход от CDMA к LTE мог занимать до двух минут. Такое признание сделала компания Verizon, обнаружив проблему в драйверах USB-модема LG введя свою сеть LTE в эксплуатацию.

МТС: Зона обслуживания сетей 3G/UMTS и 2G/GSM в Краснодарском крае, июнь 2011 года

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

Погодный сервис может отказаться от загрузки объемных метеокарт. Программа навигации может перейти только на карты с векторной графикой, запретив на время растровые, спутниковые. Почтовый клиент, обнаружив «быструю» сеть, получит полные сообщения, а в «медленной» только заголовки. Приложение IM при передаче Вам файла, если скорость передачи низкая, отправит его на сервер, а потом, когда параметры доступа улучшатся, переместит его на мобильный терминал.

Как видите, применений много. Это не говоря уже о Windows, антивирусах и ряда других программ, которые «видя» положение триггера, в мобильной или проводной сети ведется работа, могут принять решение «обновиться», или отложить этот процесс. Согласитесь, было бы удобно для пользователя, чтобы Windows за обновлениями «лез» только из проводной сети. Правда, пока это мечты. Сейчас определить тип сети по скорости передачи и времени задержки не всегда возможно, так как одни и те же значения могут говорить, что устройство находится в «перегруженной» проводной сети, или в «недогруженной» сети LTE.

Естественно, можно указать и третий нюанс, и четвертый, и пятый. Указанными в статье двумя пунктами все тонкости не заканчиваются. Как вариант, стоило бы рассмотреть нюанс с размером и частотой запросов в приложениях, работающих в сетях GSM с GPRS/EDGE, где в силу сетевых ограничений и частых ошибок в передаче лучше запрашивать «меньше, но чаще». И в сетях LTE, где можно и даже нужно увеличивать объем запросов.

Впрочем, давайте остановимся, а другие нюансы оставим на усмотрение тех, кто будет писать приложения, программистов. Пускай это будет их «головная боль», … ну или тех, кто будет потом «отлавливать» незадачливых «быдлокодеров», то есть их творения, эксплуатируя свои сети.

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/20789/zaglyanut-vpered-kakimi-budut-prilojeniya.html

Комментарии:(12) комментировать

11 июля 2011 - 20:15
Robot_NagNews:
#1

Материал:
Говорят, «дорога в ад выстлана благими намерениями». В этом отношении сразу вспоминается история середины 2009 года. После выпуска Apple новой прошивки для iPhone, где для экономии заряда аккумулятора включили функцию «быстрого покоя», сети 3G некоторых операторов оказались «наводнены» сигнальными сообщениями. Стремясь перейти в неактивный режим, iPhone запрашивал RNC (контролер базовых станций) о прекращении соединения и высвобождении сигнальных каналов. Устройство преждевременно просило разъединить, а затем запрашивало обратное соединение с сетью. Как заявили в AT&T, в крупных городах, таких как Нью-Йорк и Сан-Франциско, работа 3G сети была нарушена.

Полный текст


12 июля 2011 - 1:10
Voicemaster:
#2

Что хотел сказать автор - непонятно.

Надеяться на то, разработчики mobile apps знают о работе GPT, TCP/IP - глупо.

Других писателей у нас нет ©.

.


12 июля 2011 - 3:19
Прохожий:
#3

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

Вообще-то определенный API в сторону приклада у мобильных платформ быть обязан. В андроиде он какой-то уже есть. Но надо бы развивать - хотя бы той той же экономии батарейки. Потому что квип на 3G батарею просто выжигает, хотя ничего особенного не делает. С лте будет еще хуже: либо не даст уходить в стендбай, либо будет постоянно будить, загружая сеть сигнализацией. Даже непонятно что хуже. И так с любым сервисом, который имеет presence control.


12 июля 2011 - 22:06
Ivan_83:
#4

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


12 июля 2011 - 22:49
vIv:
#5

Ну если на каждый чих выключать 3G и включать при каждом пакетике, - то да.


13 июля 2011 - 1:19
SergeiK:
#6

А как иначе? Пересылать редкие мелкие пакеты не через 3G/LTE а GSM/GPRS?
Не знаю, как это возможно технически, но звучит реализуемо.

Вопрос, на сколько это поможет сохранить энергию батарейки?


13 июля 2011 - 11:57
Прохожий:
#7

Просмотр сообщенияSergeiK (13 июля 2011 - 00:19) писал:

А как иначе? Пересылать редкие мелкие пакеты не через 3G/LTE а GSM/GPRS?


Идеальный вариант на самом деле.

Физика нам каг-бэ намекает на то, что чем шире полоса - тем энергетически дороже. ГПРС отлично справляется с приложениями типа Аси. У меня на одном из телефонов вообще 3Г выключен принудительно.

Просмотр сообщенияSergeiK (13 июля 2011 - 00:19) писал:

А как иначе? Пересылать редкие мелкие пакеты не через 3G/LTE а GSM/GPRS?


Идеальный вариант на самом деле.

Физика нам каг-бэ намекает на то, что чем шире полоса - тем энергетически дороже. ГПРС отлично справляется с приложениями типа Аси. У меня на одном из телефонов вообще 3Г выключен принудительно.


17 июля 2011 - 11:25
nuclearcat:
#8

ИМХО пофигу - 3G/LTE/GPRS, если приложение вынуждено слать keepalive пакеты каждые 30-60 секунд - это зло. А оно вынуждено, ибо в большинстве сетей - NAT. Если NAT-а нет - оно вынуждено принимать мусор на реальник еще чаще.

Поэтому скорее тут даже не совсем API нужно для управления соединением, а хитрый offload TCP/UDP на сторону оператора, или даже offload части приложения. К примеру если аська висит и ничего не принимает, клиентский терминал ничего не получает, а если что-то пришло оператору, на что клиент "подписался" (status event определенного человека, сообщение и т.п.) - то приезжает каким-нить push методом заложенным в спецификации сети.

Кстати новая статья дохода, плюс новый тип сервис модного cloud сервиса оператора, вместо выжимания последних капель средствами QoS (тарификация по типу траффика и вечная борьба меча и орала) :-) Конкурировать кому-либо с оператором будет сложно, т.к. нужен доступ к определенной функциональности сети.


17 июля 2011 - 21:16
Ivan_83:
#9

Не осилят. Хотя я мельком видел как местный оператор аську реализовал через смс чтоли.


18 июля 2011 - 2:23
nuclearcat:
#10

Если припрет - осилят.
Для них это реальный шанс получить преимущество перед third party applications и снова "оседлать коня", или хотя бы взять под контроль ситуацию (скооперироваться с разработчиками аппликух).
Т.к. тот же скайп реально кушает траффик и батарею.

Самый простой вариант - засунуть сервера приложений в "серую" сеть, где и клиенты и убрать необходимость посылать кипалайвы, и перейти к полноценной push модели.


Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться