Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>>Подскажите плиз чем и как сделать непрерывно открытый сокет под Tomcat. Чтобы клиент отдал запрос на 8080, после чего клиент и сервер гоняют данные туда-сюда без всяких там HTTP-заголовков и прочей лабуды.

ANS>Use "Comet", Luke!

В дополнение могу дать ссылку на новую технологию Adobe'а BlazeDS(beta), данная технология будет актуальна для Flash клиентов. Также можно посмотреть результаты тестов здесь.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Вопрос только в том, как клиент ухитряется непрерывно слать данные через это соединение. Протокол Bayeux предполагает только непрерывную отдачу сервера.

Действительно, интересно. Я не знаю наверняка, но могу предположить. Согласно http в хедере клиентского запроса POST должен быть указан размер пересылаемых данных. Это и есть главная проблема. Например, стандартный http клиент URLConnection даже не отправляет запрос (накапливает в буфере), пока не открыть inputThread (или попытаться прочитать HttpResponseCode), т.е. пока явно не перейти к чтению ответа, тем самым дав понять, что запрос окончательно сформирован. Но ведь можно использовать и самописный клиент. Открыть сокет, сформировать http хедер с указанием очень большого размера сообщения и отправлять данные по мере необходимости. Важно, чтобы сервера в интернете не вели себя подобно URLConnection, т.е. не накапливали данные, а сразу передавали по цепочке (что в их же интересах). Возможно, для этого надо указать в хедере режим chunked. И получится постоянное соединение. Однако на приемной стороне на каждое соединение обычно выделяется поток, что плохо, потому что количество потоков лимитировано. Поддержка этой технологии в Томкате стала возможна, когда реализовали обработку http запросов средствами nio, т.е. операции ввода\вывода всех клиентов обрабатываются одним потоком. Понятно, что должны быть также worker потоки, но все равно эффективность использования ресурсов выше.

Здравствуйте, Дм.Григорьев, Вы писали:

C>>Дополню: его очень удобно использовать в Jetty.
ДГ>При использовании голых Continuations, сервер может отдавать клиенту данные, не закрывая HTTP response. Но клиент вынужден выполнять отдельный HTTP-запрос на каждую передачу. Сейчас смотрю сниффером написанный на флеше игровой портал, там флеш гонит на сервер данные, не выполняя отдельного HTTP-запроса на каждый пакет. HTTP-запрос выполняется только в самом начале, при установлении соединения. Причём на порт 80.
Такое тоже можно сделать — просто в сервлете пишешь в ServletOutputStream и не забываешь делать flush().

Проблема одна — на каждого клиента требуется по потоку.