Full duplex HTTP

[Juriy_84]

Добрый день.

Сразу прошу прощения, если вопрос простой и очевидный, я не так давно занимаюсь ActionScript.

Как правильно реализовать Full Duplex HTTP подключение средствами ActionScript? Другими словами, нужно добиться, чтобы и клиент и сервер могли передавать сообщения без необходимости каждый раз инициировать подключение.
Я знаю, что такой эффект можно получить, используя Transfer-Encoding=Chunked либо установив 2 постоянных подключения к серваку. И то и другое требует некоторых "танцев с бубном", если кто-то делал подобные решения, подскажите, как лучше решить задачу.

Если интересно, зачем такое счастье надо: некоторые особо злостные прокси режут не-HTTP траффик. Хочу обойти это ограничение, сохранив время реакции как при TCP подключении.

[wvxvw]

Флеш не умеет посылать нужные вам заголовки - так что варианты: вешать сокет на 80-й порт / пользоваться ФМС или аналогами.

[7thsky™]

Есть реализации Cometа под АС3 - через URLStream

[Juriy_84]

А где на эту реализацию можно посмотреть? Уж очень интересно...

... Кажется, нашел нечто подобное. Нужно было гуглить не по ActionSctipt HTTP Duplex, а по ActionScript Comet. Спасибо!

[TimID]

2J, я только что об этом распрашивал (в теме про постоянный канал подключения). Видимо, нужно писать собственный протокол.

[Juriy_84]

Я бегло прочел эту тему. Там, вроде, решения для моей задачи нет.

В Java-клиенте я делал так: создавал один запрос на сервер и оставлял его подключенным. Сервер заранее не сообщал content-length и посылал сообщения по мере надобности + keep-alive сообщения (чтобы слишком умные прокси не убивали подключение по таймауту). Получается, что сервер шлет "бесконечный" ответ.
Для сообщений от _клиента_ я каждый раз создавал новое подключение, из-за этого счастье от постоянного первого подключения сводилось на нет. Это half-duplex (или simplex, как больше нравится).
Для full duplex по такому принципу нужно по 2 постоянных подключения на каждого пользователя, это довольно дорого. Есть еще альтернативные способы (ломиться на порт 443 с запросом CONNECT) но это тоже танцы с бубном.

Насчет протокола... Поверх HTTP придумать протокол обмена сообщениями не проблема. Если траффик не критичен, я бы использовал JSON (или XML) если критичен, то нужно использовать какую-нибудь бинарную сериализацию. В своем проекте я написал небольшой движок для сериализации, основанный на аннотациях... В принципе, я им полностью доволен.
На крайняк и JSON и XML отлично сжимаются ZIP. Алгоритм сжатия/распаковки не слишком прожорлив, должно сработать.

[TimID]

Это мысль, кстати, послать заголовок http запроса в content-length которого указать заведомо большое число - метр, к примеру. Потом keep-alive и слать по сто байт в секунду. Типа: "У нас медленный коннект" - модем плохой. Сервер - тоже в ту же игру может поиграть.
Это можно на неблокирующих (асинхронных) сокетах провернуть.

Беда в том, что промежуточные сервера могут буферизировать трафик. Равно как и сам flash. Обычно буфер около 8 кб. Как их всех "отучить" от подобной самодеятельности - вопрос.
Можно попробовать слать по 10 кб за раз. Но тогда трафик может быть большим.

[BlooDHounD]

TimID, 90% проксей ваще не держат кип-элив.

[TimID]

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

TimID, 90% проксей ваще не держат кип-элив.

Значит остается 443 и CONNECT.
Или наладить 4-8 сокетов соединяться с сервером в "замедленном режиме" с небольшим перекрытием. Чтобы сеанс длился секунд 10-15 (более длительный waiting определенно режется проксями как зависший).
Скажем:
Два - пытаются соединиться
Третий отправляет заголовок
Четвертый - тело
Пятый - уже завершает
Шестой - "отдыхает" в пуле.
И т.д.

[BlooDHounD]

TimID, удачи! расскажите, что получилось