Есть куча вопросов: вот начал писать столкнулся с такой проблемой.

У меня структура чата такая 

есть сервер и клиенты . Все клиенты соеденены с сервером.
  

Для каждого клиента создается отдельный поток для чтения и записи.
У меня ни как не получается прочитать сообщение от клиента. Я пытаюсь сделать это так.


message это обьект , который содержит в себе сообщение , код сообщения и и ник клиента  , который положил это сообщение.
Вот!
Мне не понятно одно , как организовать общение между клиентом и сервером , когда неизвестно в какой момент времени клиент пошлет сообщение , и неизвестно в какой момент ответит сервер. Можно вместо BufferedReader написать InputStream и методом read (read блокирует поток , то есть ждет пока клиент что нить напишет , а это и нужно )прочитать сообщение по байтого , но так не пойдет потому , что чат должен поддерживать unicode.
За любой совет буду рад , спасибо заранее. 

1. Вот реализации Jabber Server и Jabber Client на Java, может проще взять их и адаптировать под свои нужды?
2. И у клиента и у сервера есть поток который ждет пока поступят данные, он может делать с блокировкой до тех пор пока не поступят данные, а может и не ждать, а проверять скажем другие соединения на предмет наличия данных. 

Спасибо ! Есть еще один вопрос , вот на днях написал чат на JAVA  используя IMAP .Столкнулся с такой проблемой как кодировка , выяснил что на самом серваке русский шрифт не понимается. Я отправляю сообщение с помощю DataOutputStream , а    принимаю соответственным Input,  приходит клякса , может кто сталкивался с такой проблемой ? 

Это сообщение отредактировал(а) JlOKu - 16.5.2006, 07:03

DataOutputStream пишет строки в кодировке UTF-8, возможно сервер требует себе другую кодировку. А вообще маловато данных, для того чтобы что-то советовать. 

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

in.read() вроде как ждет до опупения, т.е. пока данные не придут мы имеет блокировку, которую ничем нельзя убрать. Но это имхо, не проблема, т.к. на каждого подключенного клиента можно просто создать отдельный Thread, который только его слушать будет. Или можно как-то иначе? 

У меня проблема в том, что когда стартует на каждого клиента по отдельному Thread на сервере для чтения, то чтение идет нормально.
Но как только я запускаю еще один Thread на сервере, который каждую секунду перебирает сокеты клиентов и шлет на них определенную информацию, то Thread в которых должно происходить считывание с клиентов - вообще ничего не читает с них. 

вот мое скромное мнение по поводу чатов:

Создавать отдельные потоки и слушать сокеты -  много лишней работы. Чтобы упростить данный процесс, можно использовать технологию Java RMI. Клиент и серевер в данном случае будут предоставлять удаленные объект друг другу. Сервер предоставит объект регистрации и входа в систему и объекты для отправки сообщений. Клиент - предоставит объект, методы которого сможет вызывать сервер, например для отправки сообщений клиенту.

Общая схема такая: 
Сервер создает один общий для всех клиентов объект, предоставляющий услугу регистрации (входа в систему) клиенту. Все клиенты вызывают методы данного удаленного объекта, чтобы попасть в чат. Например, данный объект будет иметь метод login(String name, char [] password, MyCallbackObject clientCallback), а возвращать (в случае успешного входа) будет объект с методами sendMessage(String message). Клиент будет вызывать данный метод когда захочет отправить сообщение.
 
Сервер создает пул объектов обратной связи с клиентами. В данный пул помещается информация о клиенте и MyCallbackObject clientCallback клиента. Как только серверу станет необходимо отправить некоторое сообщение клиенту, он выберет из пула объект clientCallback нужного ему клиента и вызовет его метод (например) sendMessage(String message). Так клиент получит свое сообщение.

Плюсами данного подхода является отсутствие постоянного цикла прослушивания сокетов. Если говорить точнее, то это цикл будет скрыт от нас высокоуровневыми механизмами RMI. 

Извиняюсь, если сумбурно изложено. Желательно, сначало ознакомится с RMI, тогда картина сильно проясниться. Впрочем это лишь мои вольные мысли. 

Там есть несколько вариантов, метода read()

• int read() - действительно блокируемый
• int read(byte[], int, int) - неблокируемый

Без кода, сложно что-то сказать.


Можно, но тут есть некоторые проблемы:
1. Оптимизировать сервер по производительности будет проблематично (а RMI все таки довольно прожорливая до ресурсов технология)
2. Клиенты могут быть только на Java


Что-то я не понял, что он будет возвращать, что за объект?

P.S. По теме рекомендую почитать: Instant Messaging in Java: The Jabber Protocols. У меня вроде где-то валялась в электронном виде. 

Согласен конечно, будут вопросы с производительностью. Тогда можно RMI компоненты заменить на EJB. Принцип один и тот же, но последний работает на сервере, который решает вопросы масштабируемости и производительности.


Ну тогда CORBA ждет...


Клиент подсоединяется к серверу, предает ему имя пользователя и пароль, на что сервер выполняет проверку клиента и в случае успеха
создаёт у себя новый RMI объект, реализующий методы отправки сообщений, и возвращает ссылку на него клиенту. Клиент получает данную ссылку (объект реально находится на стороне сервера) и использует её (вызывает методы) для отправки сообщений. Получается что-то вроде RMI CallBack-а, но не он. Так для каждого клиента будет свой RMI объект работающий на сервере, методы которых будут использованны для отправки сообщений. 

 

Тогда он должен зарегистрировать этот объект в RMI-registry под новым именем и отправить это имя клиенту, и тот тогда сможет сделать lookup. Но на самом деле это плохо, т.к. имена всех зарегистрированных в RMI-registry объектов можно узнать, и можно тогда писать от имени любого клиента. 

Нет, этого не нужно делать. Достаточно вернуть ссылку на объект, который унаследован от UnicastRemoteObject. 


  

Это сообщение отредактировал(а) MoonCat - 2.7.2006, 20:43

 
я не понимаю -- зачем по треду на клиента? Почему не использовать один тред, который будет получать/идентифицировать сообщение и выдавать объекты с нужной инфонмацией?
Пожалуйста, объясните.

Так проще. Тред обслуживает только один сокет, т.е. читает данные до опупения.
Если будешь работать с одним тредом, то будет проблема в том, что например не все данные от клиента пришли. Значит надо или ждать пока дойдут оствашиеся, что неприемлимо поскольку остальные клиенты будут ждать, и вообще не факт что данные дойдут вообще. Или создавать временный буфер куда класть данные полученные частично, но тут свои заморочки.

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