Сокетное соединение, работающее через прокси сервер

[Vreden]

Задача реализовать постоянное соединение, которое сможет дергать сервер.

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

Меня интересует вопрос, как реализуются в таком случае чаты в играх и прочие функции, требующие отправки пакетов клиенту сервером?

P.S. RFC2817Socket не решил проблему.

[chamele0n]

http://www.flasher.ru/forum/showthread.php?t=201984

[caseyryan]

Сообщение от chamele0n

http://www.flasher.ru/forum/showthread.php?t=201984

какое это имеет отношение к данному вопросу?

Меня интересует вопрос, как реализуются в таком случае чаты в играх и прочие функции, требующие отправки пакетов клиенту сервером?

Обычно это реализуется через http. Так называемый http-failover. Совсем не так хорошо как сокеты, но проблему решает (хотя не любую)
клиент по таймеру шлет запрос, сервер отвечает

[Vreden]

Сообщение от caseyryan

Обычно это реализуется через http. Так называемый http-failover. Совсем не так хорошо как сокеты, но проблему решает (хотя не любую)
клиент по таймеру шлет запрос, сервер отвечает

Нет, к сожалению это не то, сервер должен сам присылать пакеты нужному клиенту без запроса от клиента. Огромное кол-во игр на флеше реализуют этот механизм, хотелось бы узнать как. Ведь эти игры работают в клиентах за фаерволлом и проксей.

Тобишь есть какой-то верный хороший способ, не костыль.

Может WebSocket? Где-то в гугле краем уха слышал, что фаерволлы и прокси пропускают их.
Но дело в том, что с сокетами я ранее не работал, почти ничего не знаю о них. И хотел бы у людей знающих поинтересоваться этой темой.

[maxkar]

WebSocket будет работать примерно тогда же, когда прокси пропускают обычные сокетные запросы (т.е. это socks прокси какие-нибудь).

Из обычных http-способов - либо периодические опросы сервера, либо long polling (в гугле есть).

[gloomyBrain]

Вообще для приема с клиента можно открыть "длинный" запрос (long polling) через URLStream. Штука удобная, по сути позволяет использовать http-протокол для установления однонаправленного соединения (клиент находится в состоянии приема ответа на свой http-запрос длительное время, почти как сокет). Единственное "но" - сейчас уже не вспомню что именно было, но с google chrome были какие-то проблемы (то ли он длину ответа как-то не так получал, то ли еще что-то). В любом случае URLStream позволяет вам через протокол http находиться в состоянии приема данных длительное время.
Что касается отправки - видимо придется воспользоваться URLLoader + URLReuquest

[Vreden]

Всем спасибо, буду юзать сокеты, а при ошибке соединения long polling