Ну вы бы как-то описали ситуацию, что ли... Ява и Флеш ан одной машине, или на разных? Флеш - это в каком виде, в браузере, или прожектор, или AIR? HTTP - это такое же сокетное соединение, кстати сказать, только порт, через который оно происходит по умолчанию открыт. Можно попробовать другие порты, объяснить пользователю, как добавить исключение в firewall (антивирусы такими вещами не занимаются обычно...). В крайнем случае можно через 80-й порт установить непрерывное соединение (long polling).

Dukobpa3, львиная доля игр, клиент-серверное сообщение которых построено на сокетах, не могут адекватно работать на http запросах. Ради полутора-двух залётных пассажиров, которые решили один раз в жизни поиграть по сети (ну иначе у них бы вопросов с сокетами скорее всего не возникло) городить дополнительные возможности? Да кому они сдались!

@Zebestov - было бы действительно "городить" - согласился бы.
А так не настолько это сложная процедура, что касательно сервера, что касательно клиента. Но соглашусь, конечно - в любом случае это доп. время на разработку.

Вадим, да нифига там сложного нет. Один раз написал и используй.
Я делал так.
1.Коннектимся по сокету по порту N1 - если косяк пробуем ещё из списка.
2.Если с сокетами голяк пробуем Long polling.
Если с ним тоже беда.
3.Тогда ping.
На сервере тоже 1 раз всё делается. Протоколы никуда не меняются. Просто вместо отправки сообщения сразу по сокету - складываем его в очередь и ждём пока клиент не соизволит спросить "есть чо?".

ерунда.
Если это не жесткий реалтайм, конечно.

Использовать в сокетах схему - запрос ответ - вообще упячка (хотя много где видел)

Ну а как тогда если надо обновить какую-то информацию не часто изменяемую?
Ну например открываю окошко лобби, мне нужно один раз запросить список активных игроков. Вся игра работает через сокет. Посылаю серверу команду: "я открыл лобби" - он мне шлет в ответ список активных игроков.

Или имелся в виду запрос-ответ с ожиданием ответа после запроса?

Просто у нас тоже есть много где система запрос-ответ, только это всё асинхронно. На сервер поступают команды по мере надобности, а сервер в свою очередь отправляет ответы когда готовы. Запрос не связан с конкретным ответом.

Сокет хорош полнодуплексом.
rpc для сокета - упячка.
запрос-ответ - упячка.
Надо:
клиент -> событие на сервер.
сервер -> событие(команду) на клиент
события содержат инфу