Управление событиями через пользовательский TCP-сервер с длительным опросом - PullRequest
0 голосов
/ 13 ноября 2009

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

То, как я пытаюсь это сделать, - это написать асинхронный TCP-сервер на C # и соответствующий TCP-клиент, также написанный на C #.

Способ, которым работает длинный опрос (насколько я понимаю), заключается в том, что вы открываете TCP-соединение с сервером, и сервер останавливается перед отправкой данных через сокет. Вы нашли интервал Heartbeat, который работает в сети мобильного телефона (я слышал, что около 8 минут работает?), И вы отправляете пустой пакет, если нет обновленных данных.

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

Поток должен быть примерно таким («клиент» на телефоне):

  1. Пользователь запускает мое приложение

  2. Клиент отправляет запрос на уведомление об изменении данных

  3. Сервер «связывает» (регистрирует) объект сокета клиента в «Обработчик событий», который вызывается другими TCP-соединениями сервера, о которых я говорил!

  4. Событие

    o Если он запущен (поступили новые данные), отправьте данные клиенту

    o Если он не запущен (нет новых данных), отправьте клиенту пакет «EmptyChanges»

  5. Клиент получает данные на телефон и обрабатывает их (вызывает обработчик событий в зависимости от типа пакета, который он получил, и передает ему «данные», полученные им с сервера)

  6. Клиент отправляет запрос на уведомление об изменении данных

Итак, моя проблема в том, что я не могу придумать дизайн, который бы достиг того, чего я хочу. Проблема в том, что я не знаю, как сделать № 3. Как «связать» один обработчик событий с другим? И они почти гарантированно будут работать в разных потоках!

Итак, мое приложение будет выглядеть примерно так (все psuedocode):

Class AppClass
{
    Main()

    List<Client> clients;
    List<DataServers> dataServers;

    DataReceivedFromServer(Data stuff)
    {
    }

    MessageReceivedFromPhone(PhoneMessage pm, object sender)
    {
        //Loop here until HeartBeat interval reached
        Int totalTime = 0;
        While(totalTime < HEARTBEAT_INTERVAL)
        {
            If( ) // If we have received data from the server, and the client WANTED that data, send it now
            {
            }
        }
    }
}

Вид? Я хочу, чтобы он был ориентирован на события, но мне непонятно, как выяснить, как управлять приложением в стиле PUSH по сравнению с тем, что я "привык" к опросу.

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

Серверная платформа: Windows

Язык сервера: C #

Тестовая клиентская платформа: Windows

Тестовый язык клиента: C #

Платформа Target Client: Windows Mobile 6.5, iPhone, Android (клиенты будут написаны отдельно)

Язык целевого клиента: C #, Obj-C или MonoTouch, Java

1 Ответ

0 голосов
/ 25 ноября 2009

Просто кому-то интересно, я отбросил идею написания собственного TCP-сервера для управления моими соединениями. Это было связано с огромными накладными расходами, и я в основном копировал бы написание своего собственного HTTP-сервера, поэтому вместо этого я использовал инфраструктуру Web Tornado в Python в качестве моего сервера и пишу серверные службы для связи через HTTP. запросы в Web Tornado.

Вместо того, чтобы использовать Длинный опрос вообще, я собираюсь использовать SMS для push-уведомлений. Я полагаю, что все основные телефонные платформы реализуют что-то похожее на перехватчик SMS, который вы пишете ... если приходит SMS определенного формата, он запускает ваш пользовательский код. Это позволяет мне убрать требования использования согласованных открытых соединений (кроме живого чата, который будет использовать длинный опрос в стиле кометы, но соединение может оставаться открытым только в том случае, если оно активно в течение примерно 5 минут).

По сути, в моей архитектуре платформа Web Tornado служит шиной Enterprise.

...