LINUX.ORG.RU

Как устранить возрастающую задержку при отправке данных через EDGE (2G)?

 , ,


0

1

Вопрос к гуру клиент-серверных приложений для мобильных сетей. Eсть клиент-серверное приложение под андроид. Клиент под Android с периодичностью раз в 100 ms отправляет UDP пакет (около 100 байт) на сервер. Одним полем данных пакета является timestamp. Время на клиенте и сервере синхронизированно. В качестве сети используется EDGE мобильного оператора. На сервере каждую секунду сравниваем timestamp полученный от клиента с текущим временем и получаем следующую картину:

Время клиента 17:30:01, время сервера 17:30:01

Время клиента 17:30:02, время сервера 17:30:02

Время клиента 17:30:03, время сервера 17:30:04

Время клиента 17:30:04, время сервера 17:30:05

Время клиента 17:30:05, время сервера 17:30:06

Время клиента 17:30:06, время сервера 17:30:07

Время клиента 17:30:07, время сервера 17:30:08

Время клиента 17:30:08, время сервера 17:30:11

Время клиента 17:30:09, время сервера 17:30:11

Время клиента 17:30:10, время сервера 17:30:11

Время клиента 17:30:11, время сервера 17:30:20

Время клиента 17:30:12, время сервера 17:30:20

Время клиента 17:30:13, время сервера 17:30:20

Время клиента 17:30:14, время сервера 17:30:21

Время клиента 17:30:15, время сервера 17:30:22

Время клиента 17:30:16, время сервера 17:30:23

Время клиента 17:30:17, время сервера 17:30:24

Время клиента 17:30:18, время сервера 17:30:25

Время клиента 17:30:19, время сервера 17:30:26

Время клиента 17:30:20, время сервера 17:30:27

Время клиента 17:30:21, время сервера 17:30:28

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

100 ms
UDP пакет
EDGE мобильного оператора
SO_SNDBUF в опциях сокета на клиенте вплоть до нуля

Мля, я вот даже не знаю с какой стороны тебя пинать ногами начинать.

anonymous ()
Ответ на: комментарий от anonymous

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

A_Klinsky ()
Ответ на: комментарий от A_Klinsky

По делу. У тебя все плохо. Ежик не рассчитан на такие «скорости». И гарантированной беззадержки тебе никто не даст. Но ты можешь у провайдера попросить выделить тебе полосу с приоритетом :]

Первое что пришло в голову это SO_SNDBUF.

Зачем оно тебе ваще с UDP? Тыб хоть в доку залез, чтоль.

Да и помимо твоих буферов есть еще провайдер с говноканалом, так что тут факторов, которые ты не можешь починить достаточно.

Ну попробуй иногда делать паузы в посылках. потелеметрил 10 секунд - отдохнул 10 секунд.

А еще есть механизмы выравнивая задержек (как у NTP например)

anonymous ()

Как ты вообще добился, чтоб у тебя и первый пакет сразу прилетел? Сейчас вот пробую по ежику себе на сервер пакет кинуть от 2 и больше секунд летит. без 100ms даже. Один из Питерских опсосов.

anonymous ()
Ответ на: комментарий от anonymous

хотя не, некоторые вот 800ms идут. Самое быстрое пока =)

anonymous ()
Ответ на: комментарий от anonymous

99% проблем с EDGE это канал между клиентом и базовой станцией. А именно периодическое отсутствие таймслотов для отправки данных (от клиента к станции) или ретрансмит битых фреймов. Задержка на EDGE когда нет лагов 400-600 ms. Лаги могут возникать на 1-10 секунд. В момент лага клиент копит данные в исходящей очереди. Суть в том, чтобы максимально сократить исходящую очередь (дропать устаревшие неотправленные пакеты). Например, чтобы длина очереди была не больше 5 сообщений. Предполагаю таким образом можно будет выровнить задержки после возникновения лага.

A_Klinsky ()
Ответ на: комментарий от Mahmood

Походу на этом форуме помощи не найти.. Видимо никто не сталкивался с нестандартными задачами android программирования..

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
10 июля 2017 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.