отправка и получение сокета java

с нескольких часов я думаю о том, как я должен использовать сокеты Java для отправки и получения данных. Я надеюсь, что вы можете помочь мне найти хороший способ сделать это.

Я построил структуру сервера/клиента, в которой клиент подключается к серверу и получает свой собственный поток, обрабатывающий метод запроса-ответа. Информация заключена в формате XML.

Вначале Сервер запускает чтение блокирующего сокета. Сначала я использую writeInt(), где передается длина XML-сообщения. После этого Сервер считывает количество байтов длины и анализирует сообщение. После передачи клиент переходит в состояние приема и ждет ответа.

Это нормально, но после того, как клиент аутентифицируется, сервер ждет, что придет, и блокирует.

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

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

Я искал некоторое время и нашел некоторую интересную информацию, но я не понял их хорошо. К сожалению, моя книга посвящена только этой простой модели сокета.

Может быть, я должен использовать два потока. Одна отправка и одно получение. На сервере есть база данных, в которой сообщения хранятся и ожидают передачи. Поэтому, когда сервер получает сообщение, он сохраняет это сообщение в базе данных, а также ответ типа «сообщение получено» будет храниться в базе данных. Поток-отправитель проверит наличие новых сообщений и отправит клиенту «сообщение получено». Этот подход не будет отправлять ответ в миллисекундах, но я мог представить, что он будет работать хорошо.

Я надеюсь, что дал вам достаточно информации о том, что я пытаюсь. Что бы вы порекомендовали мне, как реализовать это общение?

Спасибо


person k.j.    schedule 18.05.2013    source источник
comment
взгляните на code.google.com/p/quickserver (скачайте ZIP-файл весь код и множество примеров для начала)   -  person tgkprog    schedule 18.05.2013


Ответы (1)


Но что мне делать, когда на сервере теперь есть информация, которую нужно передать.

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

Более простая модель может состоять из двух розеток. Один сокет работает так же, как и вы сейчас, и когда вы «логинитесь», клиенту отправляется уникальный идентификатор. В этот момент клиент открывает второе соединение с выделенным потоком для прослушивания асинхронных событий. Он передает уникальный идентификатор, чтобы сервер знал, для какого клиента предназначены асинхронные сообщения.

Это даст вам простой синхронный шаблон, который у вас есть сейчас, и простой асинхронный шаблон. Единственным недостатком является то, что у вас есть два сокетных соединения, и вы должны их координировать.

person Peter Lawrey    schedule 18.05.2013
comment
это было бы нормально для нескольких клиентов, но для нескольких клиентов вы бы потратили впустую сокеты - person tgkprog; 18.05.2013
comment
@tgkprog Какова стоимость потраченного впустую сокета? ;) - person Peter Lawrey; 18.05.2013
comment
существует жесткое ограничение на сокеты для ОС. Не имеет значения, если у вас есть несколько тысяч сайентов, но я видел ошибки вне сокета с узлами jboss, когда много клиентов подключались из Интернета, и мы подключались к HSM, dbs, другим ресурсам - все это в одна точка является сокетом. - person tgkprog; 18.05.2013
comment
я просто думаю, что когда нужен хороший протокол (рукопожатие, мета, данные) - person tgkprog; 18.05.2013
comment
@tgkprog В целом согласен. Сложность заключается в том, что синхронные вызовы ожидают ответа, в то время как асинхронные события могут быть отправлены до или после них. т. е. клиентский ридер усложняется. - person Peter Lawrey; 18.05.2013