Здравствуйте!
Есть приложение, которое должно постоянно работать. Для проверки работоспособности 24/7/365 приложение каждые 30 секунд отправляет свой идентификатор серверу.
Проблема 1: приложение потребляет много трафика. Каждый запрос это в среднем 360 байт отправленных и 160 байт полученной информации. В сумме 520 байт за запрос. Т.е. в минуту 1кб, в час 60кб, в день , 1.4Мб, в месяц 43мб, что при средней цене 7 руб за мб получается 300 руб.
Вопрос1: как уменьшить объем трафика, если приложению нужно всего лишь отправить 2 раза в минуту один числовой идентификатор, а получать вообще ничего не надо? Почему сейчас все равно какие-то байты получаются, если я ничего не читаю из потока? (см. код ниже)
Вопрос2: в эту паузу (30 сек) телефон по ходу дела закрывает интернет-сессию (на моем сонэрике исчезает значок глобусика), поэтому мегафон тарифицирует это одно соединение и округляет сразу до 300 кб. Этого не происходит, если интервал между запросами уменьшить, например, до 5 секунд, но тогда резко возрастает трафик и потребление аккаумулятора.
Вопрос, как заставить телефон не закрывать сессию соединения с телефоном?
Использую следующий код:
try{
SocketConnection sc = (SocketConnection)
Connector.open("socket://serverurl:serverport");
OutputStream os = null;
try{
os = sc.openOutputStream();
byte[] data = "ID:27563".getBytes();
os.write(data);
} finally{
sc.close();
os.close();
}
} catch (IOException x){
}
Здравствуйте, Anvar, Вы писали:
A>Как уменьшить объем траффика?
A>Есть приложение, которое должно постоянно работать. Для проверки работоспособности 24/7/365 приложение каждые 30 секунд отправляет свой идентификатор серверу.
Увеличить интервал пинга.
A>Вопрос1: как уменьшить объем трафика, если приложению нужно всего лишь отправить 2 раза в минуту один числовой идентификатор, а получать вообще ничего не надо? Почему сейчас все равно какие-то байты получаются, если я ничего не читаю из потока? (см. код ниже)
Ты используешь достаточно высокоуровневый протокол. Есть же и служебные данные: запросы на коннект, подтверждение получения пакета и т.д. Кстати, как смотришь конкретные данные на запрос, через счетчик самого телефона?
A>Вопрос2: в эту паузу (30 сек) телефон по ходу дела закрывает интернет-сессию (на моем сонэрике исчезает значок глобусика), поэтому мегафон тарифицирует это одно соединение и округляет сразу до 300 кб. Этого не происходит, если интервал между запросами уменьшить, например, до 5 секунд, но тогда резко возрастает трафик и потребление аккаумулятора. A>Вопрос, как заставить телефон не закрывать сессию соединения с телефоном?
Ответ напрашивается сам собой — не закрывать соединение с сервером. Если для своего сервера это невозможно, то найти какой-нибудь надежный в плане постоянного соединения сервер в интернете. Та же аська, джаббер, например.
До 300 Кб — это какой Мегафон округляет? Ты вроде из Москвы, тут округление до 100 Кб. Как вариант — подключить соответствующий тариф, заточенный на интернет, или подключить GPRS-пакет. И в том, и в другом случае округление будет до 1 Кб.
Здравствуйте, Donz, Вы писали:
D>Увеличить интервал пинга.
Это невозможно, т.к. если суть системы такова, что если сервер остается без связи с мобильным телефоном более чем на минуту, это критическая ситуация и надо срочно бежать смотреть, что там с девайсом.
A>>Вопрос1: как уменьшить объем трафика, если приложению нужно всего лишь отправить 2 раза в минуту один числовой идентификатор, а получать вообще ничего не надо? Почему сейчас все равно какие-то байты получаются, если я ничего не читаю из потока? (см. код ниже)
D>Ты используешь достаточно высокоуровневый протокол. Есть же и служебные данные: запросы на коннект, подтверждение получения пакета и т.д. Кстати, как смотришь конкретные данные на запрос, через счетчик самого телефона?
Смотрю через счетчик телефона. Хочется по-минимуму передавать эти служебные данные. Можно это как-нибудь подправить?
D>Ответ напрашивается сам собой — не закрывать соединение с сервером. Если для своего сервера это невозможно, то найти какой-нибудь надежный в плане постоянного соединения сервер в интернете. Та же аська, джаббер, например.
Сервер свой, выделенный, с этим проблем нет. Вопрос, насколько это архитектурно правильно: открыть коннект и постоянно его держать открытым, но, видимо, так и придется.
D>До 300 Кб — это какой Мегафон округляет? Ты вроде из Москвы, тут округление до 100 Кб. Как вариант — подключить соответствующий тариф, заточенный на интернет, или подключить GPRS-пакет. И в том, и в другом случае округление будет до 1 Кб.
Да, вроде бы до 100Кб, хотя где-то я видел приписку про 300, видимо, ошибся. Насчет пакетов — это понятно. Это, скажем так, уже второй этап оптимизации — со стороны юзера.
Здравствуйте, Anvar, Вы писали:
A>Смотрю через счетчик телефона. Хочется по-минимуму передавать эти служебные данные. Можно это как-нибудь подправить?
Думаю, что нет. Служебные данные — это необходимые пакеты TCP/IP. В любом случае в мобильной яве ниже сокетов не достучаться, а в обычном телефоне навряд ли будут подобные настройки, если они вообще возможны.
D>>Ответ напрашивается сам собой — не закрывать соединение с сервером. Если для своего сервера это невозможно, то найти какой-нибудь надежный в плане постоянного соединения сервер в интернете. Та же аська, джаббер, например. A>Сервер свой, выделенный, с этим проблем нет. Вопрос, насколько это архитектурно правильно: открыть коннект и постоянно его держать открытым, но, видимо, так и придется.
А что такого? Единственная загвоздка, а выдержит ли сервер большое число одновременных коннектов, если очень много пользователей. Но при коннектах с одного клиента каждые тридцать секунд, постоянное соединение может даже разгрузить сервер, хотя зависит от типа коннекта.
A>Вопрос1: как уменьшить объем трафика, если приложению нужно всего лишь отправить 2 раза в минуту один числовой идентификатор, а получать вообще ничего не надо? Почему сейчас все равно какие-то байты получаются, если я ничего не читаю из потока? (см. код ниже)
Переходите на UDP.
Сервачок соотвественно переточить под UDP.
A>Вопрос, как заставить телефон не закрывать сессию соединения с телефоном?
В общем случае — никак. А по жизни — если поднять keep-Alive HTTP соединение, то вроде как телефон держит.
Здравствуйте, Protey, Вы писали:
P>Переходите на UDP.
P>DatagramConnection dc = (DatagramConnection)Connector.open("datagram://serverurl:serverport"); P>Datagram dobject = dc.newDatagram(message, length, destAddr); P>dc.send(dobject);
В UDP служебной информации точно меньше? Кстати, доставка не гарантирована, для проекта автора не лучшее решение.
A>>Вопрос, как заставить телефон не закрывать сессию соединения с телефоном? P>В общем случае — никак. А по жизни — если поднять keep-Alive HTTP соединение, то вроде как телефон держит.
Если вопрос в экономии трафика, то лучше реализовать пинг через сокеты или тот же UDP. HTTP еще больше раздувает запросы.
Здравствуйте, Donz, Вы писали:
D>В UDP служебной информации точно меньше? Кстати, доставка не гарантирована, для проекта автора не лучшее решение.
Как минимум на 3 IP пакета меньше Доставка и в случае TCP не гарантирована, TCP гарантирует целостность, но не качество доставки.
A>>>Вопрос, как заставить телефон не закрывать сессию соединения с телефоном? P>>В общем случае — никак. А по жизни — если поднять keep-Alive HTTP соединение, то вроде как телефон держит.
D>Если вопрос в экономии трафика, то лучше реализовать пинг через сокеты или тот же UDP. HTTP еще больше раздувает запросы.
Сложный вопрос.
Во многих телефонах HTTP ходит через оптимизированую либу, расшаренную с браузером, за счет чего отрубание сессий МОЖЕТ проходить сильно реже.
В случае сокетов — пинги канала МГОУТ быть сильно чаще.
Во всяком случае во Opera Mini 2 сей приём пользовали.
Здравствуйте, Protey, Вы писали:
P>Как минимум на 3 IP пакета меньше Доставка и в случае TCP не гарантирована, TCP гарантирует целостность, но не качество доставки.
Могу ошибаться, но в TCP гарантируется или доставка пакета, или возникновение ошибки, говорящей о недоставке пакета. В UDP такого нет.
D>>Если вопрос в экономии трафика, то лучше реализовать пинг через сокеты или тот же UDP. HTTP еще больше раздувает запросы.
P>Сложный вопрос. P>Во многих телефонах HTTP ходит через оптимизированую либу, расшаренную с браузером, за счет чего отрубание сессий МОЖЕТ проходить сильно реже. P>В случае сокетов — пинги канала МГОУТ быть сильно чаще. P>Во всяком случае во Opera Mini 2 сей приём пользовали.
Конкретно в данном случае пакет должен ходить каждые тридцать секунд, так что, ИМХО, не подходит тут ни keep-alive, ни хитрое устройство телефонного хттп.
Для Оперы Мини, кстати, делают специальные моды, которые удерживают соединение, так как стандартный дистриб его все равно отрубал.
Доставка и в случае TCP не гарантирована, TCP гарантирует целостность, но не качество доставки.