Подскажите плиз чем и как сделать непрерывно открытый сокет под Tomcat. Чтобы клиент отдал запрос на 8080, после чего клиент и сервер гоняют данные туда-сюда без всяких там HTTP-заголовков и прочей лабуды.
Также интересует, какого максимального количества одновременно открытых сокетов можно достичь на выделенном сервере.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Всем привет.
ДГ>Подскажите плиз чем и как сделать непрерывно открытый сокет под Tomcat. Чтобы клиент отдал запрос на 8080, после чего клиент и сервер гоняют данные туда-сюда без всяких там HTTP-заголовков и прочей лабуды.
ДГ>Также интересует, какого максимального количества одновременно открытых сокетов можно достичь на выделенном сервере.
Мне кажется что у работы томкат да впрочем и любого сервлет контейнера принципиально другой принцып работа.
http protocol ето stateless protocol(который работает по принцыпу запрос -- ответ).То что вы хотите сделать ето должен
быть какой небудь самописный socket server или использовать технологию ejb statefull beans , но ето уже не томкат а кокой небудь аппсервер типа jboss.Использование томкат в вашей задаче ето обязательное условие ???
Re[2]: (Tomcat) Непрерывно открытый сокет? Максимум одноврем
Здравствуйте, RobinHood, Вы писали:
RH>Мне кажется что у работы томкат да впрочем и любого сервлет контейнера принципиально другой принцып работа. RH>http protocol ето stateless protocol(который работает по принцыпу запрос -- ответ).
Угу.
RH>То что вы хотите сделать ето должен быть какой небудь самописный socket server
Мне пока в голову пришло только вешать <listener> в web.xml, чтобы он сам слушал какой-нить порт, отличный от 8080.
RH>или использовать технологию ejb statefull beans,
А с какого бока их можно прикрутить? Я имею в виду, что посадить резидентом сервис я и под томкатом смогу (см. выше). А SFSB предоставляют какие-нить удобства для работы с сокетом?
В двух словах, что мне нужно — это паттерн Observer, где генератор событий на Java-сервере, слушатели — на клиентах, причём клиентов до хрена и оповещаться они должны быстро. Если до хрена клиентов сервер не потянет, будем втыкать кластер.
RH>но ето уже не томкат а кокой небудь аппсервер типа jboss. Использование томкат в вашей задаче ето обязательное условие ???
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Всем привет.
ДГ>Подскажите плиз чем и как сделать непрерывно открытый сокет под Tomcat. Чтобы клиент отдал запрос на 8080, после чего клиент и сервер гоняют данные туда-сюда без всяких там HTTP-заголовков и прочей лабуды.
А по какому протоколу они будут гонять? Если HTTP, то никак, если другой протокол, то собственно и HTTP лабуды нет.
ДГ>Также интересует, какого максимального количества одновременно открытых сокетов можно достичь на выделенном сервере.
Я думаю это от операционки зависит.
Re[3]: (Tomcat) Непрерывно открытый сокет? Максимум одноврем
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, 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 (и тучу всяких
других вкусностей).
Re[2]: (Tomcat) Непрерывно открытый сокет? Максимум одноврем
Здравствуйте, Trean, Вы писали:
T>А по какому протоколу они будут гонять? Если HTTP, то никак, если другой протокол, то собственно и HTTP лабуды нет.
Я уже почти убедил сам себя, что нужен самописный сокет-сервер.
ДГ>>Также интересует, какого максимального количества одновременно открытых сокетов можно достичь на выделенном сервере. T>Я думаю это от операционки зависит.
Linuх. Что там нынче на сервера модно ставить? CentOS 5?
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Подскажите плиз чем и как сделать непрерывно открытый сокет под Tomcat. Чтобы клиент отдал запрос на 8080, после чего клиент и сервер гоняют данные туда-сюда без всяких там HTTP-заголовков и прочей лабуды.
ДГ>В двух словах, что мне нужно — это паттерн Observer, где генератор событий на Java-сервере, слушатели — на клиентах, причём клиентов до хрена и оповещаться они должны быстро. Если до хрена клиентов сервер не потянет, будем втыкать кластер.
Гм, я не знаю требований, но может вам что-нибудь поверх UDP (unicast/multicast) прикрутить используя Apache MINA? Так работает скайп, все биржи и пр. Единственно, что надо в application layer гарантировать упорядоченность пакетов и обрабатывать потерянные пакеты (если необходимо). Быстрее UDP врядли что-то есть, но конечно это посложнее будет, чем использовать какой-нибудь remoting-протокол.
Re[4]: (Tomcat) Непрерывно открытый сокет? Максимум одноврем
Здравствуйте, Trean, Вы писали:
T>Гм, я не знаю требований, но может вам что-нибудь поверх UDP (unicast/multicast) прикрутить используя Apache MINA?
Заманчиво, но не пойдёт. TCP-only. Да и не по срокам мне ручками организовывать надёжную доставку. Я вообще надеялся этот слой за пару дней сделать, наивный.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, Trean, Вы писали:
T>>Гм, я не знаю требований, но может вам что-нибудь поверх UDP (unicast/multicast) прикрутить используя Apache MINA?
ДГ>Заманчиво, но не пойдёт. TCP-only. Да и не по срокам мне ручками организовывать надёжную доставку. Я вообще надеялся этот слой за пару дней сделать, наивный.
Ну выбор у вас небольшой: использование чужого протокола поверх TCP, использование самописного, плюсы и минусы думаю понятны. Apache MINA работает как с UDP так и с TCP/IP сокетами.
Re[6]: (Tomcat) Непрерывно открытый сокет? Максимум одноврем
Здравствуйте, Trean, Вы писали:
T>Ну выбор у вас небольшой: использование чужого протокола поверх TCP, использование самописного, плюсы и минусы думаю понятны. Apache MINA работает как с UDP так и с TCP/IP сокетами.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ДГ>>Подскажите плиз чем и как сделать непрерывно открытый сокет под Tomcat. Чтобы клиент отдал запрос на 8080, после чего клиент и сервер гоняют данные туда-сюда без всяких там HTTP-заголовков и прочей лабуды. ANS>Use "Comet", Luke!
Дополню: его очень удобно использовать в Jetty.
Здравствуйте, 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 и т.п.?
Re[4]: Comet + Flash client = как-то не по-человечески...
От:
Аноним
Дата:
31.01.08 21:08
Оценка:
HTTP-запрос выполняется только в самом начале, при установлении соединения. Причём на порт 80.
это и есть Comet. Эта технология несколько нарушает контракт http протокола , но.. работает. Порт 80 не занят для других соединений. В Томкате 6 есть поддержка Comet.
Re[5]: Comet + Flash client = как-то не по-человечески...
Здравствуйте, <Аноним>, Вы писали:
А>это и есть Comet. Эта технология несколько нарушает контракт http протокола , но.. работает. Порт 80 не занят для других соединений. В Томкате 6 есть поддержка Comet.
Вопрос только в том, как клиент ухитряется непрерывно слать данные через это соединение. Протокол Bayeux предполагает только непрерывную отдачу сервера.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>>Подскажите плиз чем и как сделать непрерывно открытый сокет под Tomcat. Чтобы клиент отдал запрос на 8080, после чего клиент и сервер гоняют данные туда-сюда без всяких там HTTP-заголовков и прочей лабуды.
ANS>Use "Comet", Luke!
В дополнение могу дать ссылку на новую технологию Adobe'а BlazeDS(beta), данная технология будет актуальна для Flash клиентов. Также можно посмотреть результаты тестов здесь.
Re[6]: Comet + Flash client = как-то не по-человечески...
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Вопрос только в том, как клиент ухитряется непрерывно слать данные через это соединение. Протокол Bayeux предполагает только непрерывную отдачу сервера.
Действительно, интересно. Я не знаю наверняка, но могу предположить. Согласно http в хедере клиентского запроса POST должен быть указан размер пересылаемых данных. Это и есть главная проблема. Например, стандартный http клиент URLConnection даже не отправляет запрос (накапливает в буфере), пока не открыть inputThread (или попытаться прочитать HttpResponseCode), т.е. пока явно не перейти к чтению ответа, тем самым дав понять, что запрос окончательно сформирован. Но ведь можно использовать и самописный клиент. Открыть сокет, сформировать http хедер с указанием очень большого размера сообщения и отправлять данные по мере необходимости. Важно, чтобы сервера в интернете не вели себя подобно URLConnection, т.е. не накапливали данные, а сразу передавали по цепочке (что в их же интересах). Возможно, для этого надо указать в хедере режим chunked. И получится постоянное соединение. Однако на приемной стороне на каждое соединение обычно выделяется поток, что плохо, потому что количество потоков лимитировано. Поддержка этой технологии в Томкате стала возможна, когда реализовали обработку http запросов средствами nio, т.е. операции ввода\вывода всех клиентов обрабатываются одним потоком. Понятно, что должны быть также worker потоки, но все равно эффективность использования ресурсов выше.
Re[4]: Comet + Flash client = как-то не по-человечески...
Здравствуйте, Дм.Григорьев, Вы писали:
C>>Дополню: его очень удобно использовать в Jetty. ДГ>При использовании голых Continuations, сервер может отдавать клиенту данные, не закрывая HTTP response. Но клиент вынужден выполнять отдельный HTTP-запрос на каждую передачу. Сейчас смотрю сниффером написанный на флеше игровой портал, там флеш гонит на сервер данные, не выполняя отдельного HTTP-запроса на каждый пакет. HTTP-запрос выполняется только в самом начале, при установлении соединения. Причём на порт 80.
Такое тоже можно сделать — просто в сервлете пишешь в ServletOutputStream и не забываешь делать flush().
Проблема одна — на каждого клиента требуется по потоку.
А можете посоветовать сабж какой-нибудь? Клиент скорее всего будет Flash 9.
