ось моє скромне думку з приводу чатів:
Створювати окремі потоки і слухати сокети - багато зайвої роботи. Щоб спростити цей процес, можна використовувати технологію Java RMI. Клієнт і серевер в даному випадку будуть надавати віддалені об'єкт один одному. Сервер надасть об'єкт реєстрації та входу в систему і об'єкти для відправки повідомлень. Клієнт - надасть об'єкт, методи якого зможе викликати сервер, наприклад для відправки повідомлень клієнту.
Загальна схема така:
Сервер створює один загальний для всіх клієнтів об'єкт, що надає послугу реєстрації (входу в систему) клієнту. Всі клієнти викликають методи даного віддаленого об'єкта, щоб потрапити в чат. Наприклад, даний об'єкт буде мати метод login (String name, char [] password, MyCallbackObject clientCallback), а повертати (в разі успішного входу) буде об'єкт з методами sendMessage (String message). Клієнт буде викликати даний метод коли захоче відправити повідомлення.
Сервер створює пул об'єктів зворотного зв'язку з клієнтами. В даний пул поміщається інформація про клієнта і MyCallbackObject clientCallback клієнта. Як тільки серверу стане необхідно відправити деякий повідомлення клієнту, він вибере з пулу об'єкт clientCallback потрібного йому клієнта і викличе його метод (наприклад) sendMessage (String message). Так клієнт отримає своє повідомлення.
Плюсами даного підходу є відсутність постійного циклу прослуховування сокетів. Якщо говорити точніше, то це цикл буде прихований від нас високорівневими механізмами RMI.
Перепрошую, якщо сумбурно викладено. Бажано, спочатку ознайомиться з RMI, тоді картина сильно прояснитися. Втім це лише мої вільні думки.
in.read () ніби як чекає до шоку, тобто поки дані не прийдуть ми має блокування, яку нічим не можна прибрати. Але це имхо, не проблема, тому що на кожного підключеного клієнта можна просто створити окремий Thread, який тільки його слухати буде. Або можна якось інакше?
Там є кілька варіантів, методу read ()
- int read () - дійсно блокується
- int read (byte [], int, int) - Неблокована
У мене проблема в тому, що коли стартує на кожного клієнта за окремим Thread на сервері для читання, то читання йде нормально.Но як тільки я запускаю ще один Thread на сервері, який щосекунди перебирає сокети клієнтів і шле на них певну інформацію, то Thread в яких має відбуватися зчитування з клієнтів - взагалі нічого не Новомосковскет з них.
Без коду, складно щось сказати.
Створювати окремі потоки і слухати сокети - багато зайвої роботи. Щоб спростити цей процес, можна використовувати технологію Java RMI.
Можна, але тут є деякі проблеми:
1. Оптимізувати сервер по продуктивності буде проблематично (а RMI все таки досить ненажерлива до ресурсів технологія)
2. Клієнти можуть бути тільки на Java
а повертати (в разі успішного входу) буде об'єкт з методами sendMessage (String message). Клієнт буде викликати даний метод коли захоче відправити повідомлення.
Щось я не зрозумів, що він буде повертати, що за об'єкт?
P.S. По темі рекомендую почитати: Instant Messaging in Java: The Jabber Protocols. У мене начебто десь валялася в електронному вигляді.