Клиент-серверное приложение. Протокол взаимодействия

@@gent · Регистрация: 19.10.2009

Студворк — интернет-сервис помощи студентам

Здравствуйте.
Сервер может обрабатывать около 300 соединений. Думал реализовать всё на сокетах, но есть одно но. Надо при определенных событиях сервера, делать уведомление всех клиентов об этом событии. Что-то некого бродкаста должно быть. Вот тут то я и не совсем понимаю, как это на сокетах реализовать(или вовсе не на сокетах). Реализовать через POST и GET запросы я так понимаю тут невозможно, ибо нужно держать соединение с клиентами и уведомлять их о событиях независимо от передачи ими данных, что HTTP не поддерживает. Кто что может подсказать по данному вопросу? Клиенты сами подключаются и отключаются.
Заранее спасибо

@Fonduee · 30.12.2012, 01:17

Нужно копать в сторону Сериализации (или тут).

@@gent · 30.12.2012, 12:38 **[ТС]**

А причем тут сериализация? Мне надо понять, как лучше общаться с клиентами, с возможностью рассылки им уведомлений.

@Fonduee · 30.12.2012, 14:14

Если бы Вы прочитали, то бы поняли зачем и не задавали глупых вопросов:

Зачем сериализация нужна?

В сегодняшнем мире типичное промышленное приложение будет иметь множество компонентов и будет распространено через различные системы и сети. В Java всё представлено в виде объектов; Если двум компонентам Java необходимо общаться друг с другом, то им необходим механизм для обмена данными. Есть несколько способов реализовать этот механизм. Первый способ это разработать собственный протокол и передать объект. Это означает, что получатель должен знать протокол, используемый отправителем для воссоздания объекта, что усложняет разработку сторонних компонентов. Следовательно, должен быть универсальный и эффективный протокол передачи объектов между компонентами. Сериализация создана для этого, и компоненты Java используют этот протокол для передачи объектов.

@mutagen · 30.12.2012, 14:41

вам может подойти что-то вроде шаблона обсервер
http://www.javenue.info/post/76
только размазанный между клиентами и сервером, ну и роль уведомителя должны забрать на себя клиенты путём периодического прихода и проверки нет ли уведомления для них

@caballero · 03.01.2013, 05:17

не совсем ясно на хрена сокеты если есть RMI в котром уже предусмотрен механизм колбэков

@mutagen · 03.01.2013, 16:53

Сообщение от caballero

не совсем ясно на хрена сокеты если есть RMI в котром уже предусмотрен механизм колбэков

в таком случае придётся париться с дополнительно секьюрностью и обработкой таймаутами умерших калбеков по причине оутейжей сети. Опять же серваку держать rmi под всех клиентов это както неэкономно в плане ресурсов

@caballero · 03.01.2013, 17:18

а с TCP секюрност ь автоматом чтоли будет?l
да и TCP держать тоже надо, так какая разница. RMI точно также юзает TCP
а хотите секюрность но JAAS в руки

@mutagen · 03.01.2013, 17:31

я вообще предлагал обсервер и поверх http его крутить или на голый сокет без разницы, лишьбы с авторизацией. держать ничего не надо, просто публикуем топик на серваке, а клиенты сами ходят проверить нет ли чё нового.
JAAS в данном случае вполне пригоден

@@gent · 06.01.2013, 14:15 **[ТС]**

Fonduee, к счастью я знаю что такое сериализация. Опять же говорю, не про это сыр бор. Я наверное просто неправильно выразился.
Благодарю за ответы, но суть уже немного не в этом. Есть реализация собственного протокола на сокетах и что-то на подобие обсервера. Я передаю собственные объекты при приеме и передаче, в которых уже считывается необходимая информация. RMI для меня будет слишком жирно делать, это всё равно что Oracle как базу для 10 людей-клиентов.
Суть вот в чем. Есть подключенные пользователи, которые пишут что-либо в консоли. Код выглядит примерно вот так.

Java
1
2
3
4
5
6
7
8
9
10
    public static void main(String[] args) throws IOException {
        bReader = new BufferedReader (new InputStreamReader(System.in));            
        getConnection();
        while (true) {
            String inputData = bReader.readLine();
            MyObject myObject = getObject(inputData);
            in.writeObject(myObject);
            ServerObject sObject = (ServerObject) out.readObject(serverObject);
            ... //TODO with serverObject
        }

Я тут упростил всё, но суть тут можно уловить. in и out потоки типа ObjectOutputStream. Суть в том, что у нас жесткий протокол получается. Мы блокируемся в цикле на вводе информации с консоли (bReader.readLine()) и (!!!) в данный момент НИЧЕГО не можем принимать. Мы примем что-либо, уже только когда придет объект с сервера. Это неправильно. Я хочу слушать поток даже ВО ВРЕМЯ того, когда клиент что-либо пишет. Надеюсь сейчас правильно объяснил.
Тут в голову приходит мысль вывести в два потока. Первый это прием данных и их отправка, другой поток как слушатель, будет читать что пришло с потока, что-то вроде

Java
1
2
3
4
5
6
7
8
9
10
11
12
            while(socket.getInputStream().available()==0) {
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException ex) {
                    ex.printStackTrace();
                }
            }
            while (socket.getInputStream().available()!=0) {
                try {                    
                      // Получение данных и работа с ними  
                } 
            }

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

Добавлено через 14 минут
И еще вопрос. Может я и перемудрил с реализацией и впору стоило ближе к стандарту подойти, но как тут реализовать на HTTP так, что бы можно было опрашивать клиентов независимо от их запросов (HTTP же не поддерживает сессию), а так же как понимать, что клиент отсоединился? Постоянно опрашивать ?
К сожалению, с HTTP не особо знаком, писал немного на JavaEE. Но там веб сервер выполнял роль приемщика запросов по указанному адресу. А тут кто будет это делать на SE?

@Fonduee · 06.01.2013, 15:50

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

Исходный Код: https://bitbucket.org/FewG/jsimplechat

@@gent · 07.01.2013, 13:12 **[ТС]**

Благодарю. Так же и поступлю в своем приложении.
Жаль конечно, что с таким разделением на потоки чтения и записи, приходится открывать на чтение и на запись единожды. Нельзя передать сокет и открыть ЗАНОВО поток на чтение, либо передавать САМ поток, ибо ObjectInputStream при создании, записывает пару байт данный самого треда, что ставит на нет более гибкое использование передачи объектов в разных потока с использованием одного сокета.

Новые блоги и статьи Все статьи Все блоги /
Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .
Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .

@@gent 16 / 16 / 2 Регистрация: 19.10.2009 Сообщений: 91

	Клиент-серверное приложение. Протокол взаимодействия 29.12.2012, 20:51. Показов 4693. Ответов 11 Метки нет (Все метки) Здравствуйте. Сервер может обрабатывать около 300 соединений. Думал реализовать всё на сокетах, но есть одно но. Надо при определенных событиях сервера, делать уведомление всех клиентов об этом событии. Что-то некого бродкаста должно быть. Вот тут то я и не совсем понимаю, как это на сокетах реализовать(или вовсе не на сокетах). Реализовать через POST и GET запросы я так понимаю тут невозможно, ибо нужно держать соединение с клиентами и уведомлять их о событиях независимо от передачи ими данных, что HTTP не поддерживает. Кто что может подсказать по данному вопросу? Клиенты сами подключаются и отключаются. Заранее спасибо 0

@Fonduee Музыка нас Связала 232 / 232 / 52 Регистрация: 26.03.2008 Сообщений: 616
	30.12.2012, 01:17
	Нужно копать в сторону Сериализации (или тут). 0

@@gent 16 / 16 / 2 Регистрация: 19.10.2009 Сообщений: 91
	30.12.2012, 12:38 [ТС]
	А причем тут сериализация? Мне надо понять, как лучше общаться с клиентами, с возможностью рассылки им уведомлений. 0

@mutagen 2587 / 2260 / 257 Регистрация: 14.09.2011 Сообщений: 5,185 Записей в блоге: 18
	30.12.2012, 14:41
	вам может подойти что-то вроде шаблона обсервер http://www.javenue.info/post/76 только размазанный между клиентами и сервером, ну и роль уведомителя должны забрать на себя клиенты путём периодического прихода и проверки нет ли уведомления для них 0

@caballero 26 / 26 / 1 Регистрация: 30.09.2011 Сообщений: 196
	03.01.2013, 05:17
	не совсем ясно на хрена сокеты если есть RMI в котром уже предусмотрен механизм колбэков 0

@caballero 26 / 26 / 1 Регистрация: 30.09.2011 Сообщений: 196
	03.01.2013, 17:18
	а с TCP секюрност ь автоматом чтоли будет?l да и TCP держать тоже надо, так какая разница. RMI точно также юзает TCP а хотите секюрность но JAAS в руки 0

@mutagen 2587 / 2260 / 257 Регистрация: 14.09.2011 Сообщений: 5,185 Записей в блоге: 18
	03.01.2013, 17:31
	я вообще предлагал обсервер и поверх http его крутить или на голый сокет без разницы, лишьбы с авторизацией. держать ничего не надо, просто публикуем топик на серваке, а клиенты сами ходят проверить нет ли чё нового. JAAS в данном случае вполне пригоден 0

@Fonduee Музыка нас Связала 232 / 232 / 52 Регистрация: 26.03.2008 Сообщений: 616
	06.01.2013, 15:50
	Не знаю на сколько тебе пригодится мой пример. Недавно для учебы писал миничат. Реализация была также - при помощи сокетов. У клиента приложение + 1 поток, который читает информацию с сервера. Ну и сам сервер + n-ое кол-во потоков для n-клиентов. На сколько это удачная реализация, судить не могу, но работает. Никто никому не мешает и ждать не приходиться: Исходный Код: https://bitbucket.org/FewG/jsimplechat 0

@@gent 16 / 16 / 2 Регистрация: 19.10.2009 Сообщений: 91
	07.01.2013, 13:12 [ТС]
	Благодарю. Так же и поступлю в своем приложении. Жаль конечно, что с таким разделением на потоки чтения и записи, приходится открывать на чтение и на запись единожды. Нельзя передать сокет и открыть ЗАНОВО поток на чтение, либо передавать САМ поток, ибо ObjectInputStream при создании, записывает пару байт данный самого треда, что ставит на нет более гибкое использование передачи объектов в разных потока с использованием одного сокета. 0