Какой путь выбрать для организации сетевого обмена данными?

Question

[Алексей Со]

Ситуация следующая - есть приложение и сайт.

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

Сейчас предыдущие разработчики просто каждые 30сек обращаются к серверу, узнают нажата ли (условная кнопка).

Всё это дико жрет ресурсы.

Есть какие-либо идеи, как уведомить андроид устройство?

Понимаю, что есть пуши, но они не гарантируют доставку + пуши в теории можно отключить.

Думал комбинированные методы - пуш+увеличить периодичность обращения.

Подскажите плиз, есть какие-то более интересные варианты?

Answer 1

[Алексей Черемисин]

Comet, нет не пробовали? У меня работает, переподключаться, правда все равно приходится, но таймаут можно сделать и 3 минуты, играет роль, только при разрыве соединения одной из сторон, когда вторая сторона этого не опознает. Все данные приходят моментально! Можнт держать и миллион соединений одновременно.
Реальзацию comet для вашего фреймворка ищем в гугле по слову comet + <фреймворк>
У меня примерно так:

from twisted.internet import reactor

class MyRequestHandler(web.RequestHandler):
    @web.asynchronous
    def get(self):
        self.write("Processing your request...")
        reactor.callLater(5, self.do_something)

    def do_something(self):
        self.finish("done!")

Answer 2

[VZVZ]

Почему бы вообще не отказаться от HTTP в пользу голого TCP (или WebSockets - тогда для сервака идеален NodeJS)?
Клиент подключается к серваку - и соединение просто остается открытым. Сервак через xxx времени отправляет пакет - клиент его тут же получает, при этом соединение по-прежнему открыто. Также и наоборот (клиент - серваку).

Сомневаюсь, что можно придумать для сетевого обмена что-то лучшее по производительности, чем голый TCP.
Если кто-то знает вариант лучше - внимательно выслушаю и буду благодарен.

Answer 3

[Алексей Со]

С точки зрения батареи - TCP или Comet будут прожорливы ?

Comments

[Александр Холодович]

Ни то, ни другое не будет прожорливым. Оно просто держит соединение и ждёт ответа. Long-polling предпочтительней по скорости разработки, ИМХО. TCP предпочтительней по нагрузке на сеть (без оверхеда типа заголовков).