Всем привет.

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

Также интересует, какого максимального количества одновременно открытых сокетов можно достичь на выделенном сервере.

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

ДГ>Всем привет.

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

ДГ>Также интересует, какого максимального количества одновременно открытых сокетов можно достичь на выделенном сервере.

Мне кажется что у работы томкат да впрочем и любого сервлет контейнера принципиально другой принцып работа.
http protocol ето stateless protocol(который работает по принцыпу запрос -- ответ).То что вы хотите сделать ето должен
быть какой небудь самописный socket server или использовать технологию ejb statefull beans , но ето уже не томкат а кокой небудь аппсервер типа jboss.Использование томкат в вашей задаче ето обязательное условие ???

Здравствуйте, RobinHood, Вы писали:

RH>Мне кажется что у работы томкат да впрочем и любого сервлет контейнера принципиально другой принцып работа.
RH>http protocol ето stateless protocol(который работает по принцыпу запрос -- ответ).

Угу.

RH>То что вы хотите сделать ето должен быть какой небудь самописный socket server

Мне пока в голову пришло только вешать <listener> в web.xml, чтобы он сам слушал какой-нить порт, отличный от 8080.

RH>или использовать технологию ejb statefull beans,

А с какого бока их можно прикрутить? Я имею в виду, что посадить резидентом сервис я и под томкатом смогу (см. выше). А SFSB предоставляют какие-нить удобства для работы с сокетом?

В двух словах, что мне нужно — это паттерн Observer, где генератор событий на Java-сервере, слушатели — на клиентах, причём клиентов до хрена и оповещаться они должны быстро. Если до хрена клиентов сервер не потянет, будем втыкать кластер.

RH>но ето уже не томкат а кокой небудь аппсервер типа jboss. Использование томкат в вашей задаче ето обязательное условие ???

Нет. JBoss годится.

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

ДГ>А SFSB предоставляют какие-нить удобства для работы с сокетом?

Общение будет (скорее всего) в XML.

ДГ>Если до хрена клиентов сервер не потянет, будем втыкать кластер.

Но хотелось бы знать, на что примерно я могу расчитывать на одном выделенном сервере. Какой у кого есть опыт?

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

ДГ>Всем привет.

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

А по какому протоколу они будут гонять? Если HTTP, то никак, если другой протокол, то собственно и HTTP лабуды нет.

ДГ>Также интересует, какого максимального количества одновременно открытых сокетов можно достичь на выделенном сервере.

Я думаю это от операционки зависит.

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

ДГ>Здравствуйте, RobinHood, Вы писали:

RH>>Мне кажется что у работы томкат да впрочем и любого сервлет контейнера принципиально другой принцып работа.
RH>>http protocol ето stateless protocol(который работает по принцыпу запрос -- ответ).

ДГ>Угу.

RH>>То что вы хотите сделать ето должен быть какой небудь самописный socket server

ДГ>Мне пока в голову пришло только вешать <listener> в web.xml, чтобы он сам слушал какой-нить порт, отличный от 8080.

RH>>или использовать технологию ejb statefull beans,

ДГ>А с какого бока их можно прикрутить? Я имею в виду, что посадить резидентом сервис я и под томкатом смогу (см. выше). А SFSB предоставляют какие-нить удобства для работы с сокетом?

ДГ>В двух словах, что мне нужно — это паттерн Observer, где генератор событий на Java-сервере, слушатели — на клиентах, причём клиентов до хрена и оповещаться они должны быстро. Если до хрена клиентов сервер не потянет, будем втыкать кластер.

RH>>но ето уже не томкат а кокой небудь аппсервер типа jboss. Использование томкат в вашей задаче ето обязательное условие ???

ДГ>Нет. JBoss годится.

сначала подумал про spring remoting , но ето мне тоже кажется не поможет. statefull bean eto тоже будет запрос -- ответ
но в рамках одной сесси.Я думаю что message driven bean тут может подойти. У тебя сервер будет генерировать события
и писать из в queue или topic(почитай в чем разница -- ето не сложно). а клиенты будут слушать и когда приходит в
очередь сообшение будут его из очереди читать.Если я не ошибаюсь в jboss очередь поддерживает cluster (и тучу всяких
других вкусностей).

Здравствуйте, Trean, Вы писали:

T>А по какому протоколу они будут гонять? Если HTTP, то никак, если другой протокол, то собственно и HTTP лабуды нет.

Я уже почти убедил сам себя, что нужен самописный сокет-сервер.

ДГ>>Также интересует, какого максимального количества одновременно открытых сокетов можно достичь на выделенном сервере.
T>Я думаю это от операционки зависит.

Linuх. Что там нынче на сервера модно ставить? CentOS 5?

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

ДГ>Я уже почти убедил сам себя, что нужен самописный сокет-сервер.

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


ДГ>...

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

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

Use "Comet", Luke!

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


ДГ>В двух словах, что мне нужно — это паттерн Observer, где генератор событий на Java-сервере, слушатели — на клиентах, причём клиентов до хрена и оповещаться они должны быстро. Если до хрена клиентов сервер не потянет, будем втыкать кластер.

Гм, я не знаю требований, но может вам что-нибудь поверх UDP (unicast/multicast) прикрутить используя Apache MINA? Так работает скайп, все биржи и пр. Единственно, что надо в application layer гарантировать упорядоченность пакетов и обрабатывать потерянные пакеты (если необходимо). Быстрее UDP врядли что-то есть, но конечно это посложнее будет, чем использовать какой-нибудь remoting-протокол.

Здравствуйте, Trean, Вы писали:

T>Гм, я не знаю требований, но может вам что-нибудь поверх UDP (unicast/multicast) прикрутить используя Apache MINA?

Заманчиво, но не пойдёт. TCP-only. Да и не по срокам мне ручками организовывать надёжную доставку. Я вообще надеялся этот слой за пару дней сделать, наивный.

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

ДГ>Здравствуйте, Trean, Вы писали:

T>>Гм, я не знаю требований, но может вам что-нибудь поверх UDP (unicast/multicast) прикрутить используя Apache MINA?

ДГ>Заманчиво, но не пойдёт. TCP-only. Да и не по срокам мне ручками организовывать надёжную доставку. Я вообще надеялся этот слой за пару дней сделать, наивный.

Ну выбор у вас небольшой: использование чужого протокола поверх TCP, использование самописного, плюсы и минусы думаю понятны. Apache MINA работает как с UDP так и с TCP/IP сокетами.

Здравствуйте, Trean, Вы писали:

T>Ну выбор у вас небольшой: использование чужого протокола поверх TCP, использование самописного, плюсы и минусы думаю понятны. Apache MINA работает как с UDP так и с TCP/IP сокетами.

Мне вот уже посоветовали

Автор: Andrei N.Sobchuck
Дата: 18.01.08

. Шикарная ссылка, сам бы я и не вспомнил про обслуживание нескольких клиентов одним потоком.

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

ANS>Use "Comet", Luke!

Спасибо огромное, именно то, что нужно. А можете посоветовать сабж какой-нибудь? Клиент скорее всего будет Flash 9.

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

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

ДГ>А можете посоветовать сабж какой-нибудь? Клиент скорее всего будет Flash 9.
Посмотрите на Jetty. Он выглядит неплохо и умеет Comet.

Здравствуйте, Cyberax, Вы писали:

C>Дополню: его очень удобно использовать в Jetty.

При использовании голых Continuations, сервер может отдавать клиенту данные, не закрывая HTTP response. Но клиент вынужден выполнять отдельный HTTP-запрос на каждую передачу. Сейчас смотрю сниффером написанный на флеше игровой портал, там флеш гонит на сервер данные, не выполняя отдельного HTTP-запроса на каждый пакет. HTTP-запрос выполняется только в самом начале, при установлении соединения. Причём на порт 80.

Вопрос: как такое сделать средствами Jetty? И стоит ли вообще? С другой стороны, если делать ручками, то как договариваться с теми, кто уже сидит на порту 80 или?

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

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

ДГ>Вопрос: как такое сделать средствами Jetty? И стоит ли вообще? С другой стороны, если делать ручками, то как договариваться с теми, кто уже сидит на порту 80 или?

Я имел в виду, что сервлет в любом случае получает готовый запрос. Или нет?.. Допустим при file upload, Servlet.service() вызывается раньше, чем файл оказался целиком на сервере. Но как сделать бесконечный "file upload", без multipart boundaries и т.п.?

HTTP-запрос выполняется только в самом начале, при установлении соединения. Причём на порт 80.

это и есть Comet. Эта технология несколько нарушает контракт http протокола , но.. работает. Порт 80 не занят для других соединений. В Томкате 6 есть поддержка Comet.

Здравствуйте, <Аноним>, Вы писали:

А>это и есть Comet. Эта технология несколько нарушает контракт http протокола , но.. работает. Порт 80 не занят для других соединений. В Томкате 6 есть поддержка Comet.

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