Связь клиент-сервер на Java - какой подход использовать? - PullRequest
Новая
       18

Связь клиент-сервер на Java - какой подход использовать?

2 голосов
/ 05 мая 2010

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

  1. Установите соединение и поддерживайте его, пока операция не будет завершена и клиент не получит ответ.
  2. Установить соединение, отправить данные, закрыть соединение. Теперь обработка выполняется, и после ее завершения сервер может установить соединение с клиентом для отправки данных.
  3. Установите соединение, отправьте данные, закройте соединение. Обработка происходит. клиент спрашивает сервер каждые n минут / секунд, если операция завершена. Если обработка завершена, клиент извлекает данные.

Мне было интересно, какой подход будет наилучшим для использования. Есть ли какой-то "де-факто" стандарт для решения этой проблемы? Насколько «дорого» открытие сокета в Java? Решение 1. мне кажется довольно неприятным, но 2. и 3. могли бы. Проблема с решением 2. заключается в том, что серверу необходимо знать, на каком порту клиент слушает, а в решении 3. добавлены некоторые издержки сети.

Ответы [ 2 ]

2 голосов
/ 05 мая 2010
  1. хорошо достаточно
  2. не будет работать во многих ситуациях, например, если клиент находится под брандмауэром, NAT и т. Д. Сервер обычно принимает входящие соединения отовсюду, рабочие столы обычно не
  3. лучше 1 только потому, что у вас не возникнет проблем при потере соединения
  4. решения 1 + 3 - установить длительное ожидание соединения с периодическим сном и повторное подключение после. Я имею в виду: подключение к серверу, ожидание данных в течение 30 секунд, если данные не получены, режим ожидания в течение 10 секунд, цикл.

Открытие сокетов иногда дорого, но не так дорого, как обработка ваших данных.

0 голосов
/ 05 мая 2010

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

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

...