Как обычно устанавливаются двусторонние соединение в интернет?

Question

[Weageoo]

Стандартная ситуация — есть клиент и сервер. В интернете обычно сервер реализует Web-сервис (XML-RPC, SOAP, WCF), клиент может легко вызывать web-методы этого сервиса. Но как обычно поступают, если серверу необходимо тоже отправлять сообщения для клинта? UDP/TCP-соединение через сокеты? Как быть с NAT-ом? Как защищают соединение? Кроме Web-сервиса нужно писать свой параллельный сервер?

Comments

[AlpenColt]

Так сервер у вас Web или нет?

[Weageoo]

Есть БД, при обновлении информации в некоторой таблице этой БД необходимо сообщить о ней клиенту (клиентам). Клиент — Windows-desktop приложение или Android-приложение для телефона.

Answer 1

[Wott]

есть 3 варианта:
— сделать на клиенте сервер и реализовать сервисы на нем — спотыкаемся на NAT, proxy
— периодически запрашивать сервер, удерживая соединение или нет ( comet, long polling и прочая — смотреть server push)
— web sockets, когда изначальное HTTP соединение от клиента к серверу удерживается и переключается в полнодуплексный.

защищается, как всегда ssl

Comments

[Weageoo]

А каким из способов лучше воспользоваться, если необходимо реализовать Windows Desktop Client для взаимодействия с сервером в глобальной сети? Насколько я знаю, server push и web sockets — «браузерные» технологии, обычно используемые для удержания соединения браузером.

[Weageoo]

Я правильно понимаю, что для реализации клиент-серверного взаимодействия по первому варианту в общем случае необходимо:
1) Проксировать TCP-соединение через SOCKS-прокси-сервер, если это требуется
2) Использовать к.-л. NAT traversal — технологию для взаимодействия с клиентами, находящимися за NAT-ом.

[Wott]

1 они браузерные ровно потому что есть в браузерах. никто не мешает реализовать их в отдельном приложении, использовать библиотеки или воспользоваться браузером как клиентом
2 да примерно так и придется, причем ручками.

Answer 2

[Олег Карнаухов]

Вы очень вовремя. Я собирался ложиться спать после прочтения учебника Cisco. Начнем с того что маршрутизаторы при работе с NAT меняют в кадре на уровне протокола TCP ip адрес отправителя и порт отправителя на случайный порт, который записывается в специальные таблицы. Когда приложение отвечает на запрос пользователя, оно фактически также посылает пакет на IP адрес указанный в заголовках транспортного уровня. То есть по сути, когда клиент послал запрос, работа через клиентский NAT-порт еще может вестись некоторое время.
Кстати вообще все это называется двухстороннее квитирование с использованием флагов и т.д.
Почитайте про модель OSI и в частности TCP/IP, создание сеансов и т.д.
Надеюсь помог чем смог.
Насчет веб-серврера и сервиса, то что вы говорите тут желательно сервис, хотя под apache есть web-сокеты и расширение под php позволяющее как раз делать это.

Comments

[Weageoo]

То есть Web-сокеты пока наиболее приемлемое решение будущего для асинхронного обмена информацией в вебе, но достаточно универсального и стабильного решения на данный момент нет?

[Sergey]

Кадры TCP? Лолшто, это в цискином учебнике такое пишут или ты сам придумал?

[Олег Карнаухов]

Прошу прощения, конечно же пакет, был сонный просто.

[nick5]

Сегмент TCP. Так ещё правильнее :)

Answer 3

[TimID]

Есть специальный тип http запросов — CONNECT — он не разрывается после передачи данных.
Проблема в том, что не все маршрутизаторы согласятся поддерживать данный запрос вне сессии ssl (она как раз реализуется через «обертку» в данный вид запроса).

Можно еще сделать иначе — «затянуть» сессию.
Если у Вас сервер не на php (вы не получите переменные пока не придет все тело запроса), а с возможностью читать прямо поток данных от клиента, то Вы можете поступить следующим образом:

Клиент устанавливает обычное POST-соединение, но отправляет не все тело, а «порциями», большими буфера (8к — по умолчанию).
Сервер, получив заголовок запроса начинает считывать данные «по-приходу» от клиента, непрерывно опрашивая сокет, обрабатывает «порции» и выдает результат в выходной поток.
Клиент получает данные, обрабатывает и шлет следующие «порции».
В целом, все очень похоже на скачку большого файла с letitbit'a.

Этот метод хорошо работает, но выглядит для прокси, как «зависшее» соединение, и они его могут «прервать».

Answer 4

[Akson87]

Клиент периодически соединяется с сервером и проверяет, есть ли для него что-нибудь новое и интересное. В общем случае иначе нельзя.

В частном случае можно пробросить порт через NAT и коннектиться к клиенту как к серверу.

Comments

[homm]

Чтобы проверять что-то новое и интересное, не нужно коннектится периодически. Нужно подконектиться один раз и висеть, пока не отвалишься.

[Akson87]

Все зависит от задачи. Месяц не провисишь:)

Answer 5

[AlpenColt]

Если ваша система работает по HTTP-протоколу, то вариантов целая куча: начиная от Comet и WebSocket, заканчивая банальными RSS-потоками.

Если же всё работает на более низком уровне, то смело берите UDP или TCP; и NAT здесь не проблема: в игровой индустрии давно умеют с этим броться.