Постоянно используйте Socket для обработки Clientsession или создавайте новую для каждого запроса

Question

Так что я довольно новичок в Sockets, и мне нужно создать приложение Server-Client-App для школы.

Я ожидаю, что клиент запросит что-то с сервера несколько раз во время его выполнения.

Я не уверен, стоит ли создавать новый java.net.Socket для каждого полученного запроса (клиент каждый раз открывает новый сокет, а Java Serversocket принимает) или используйте один сокет и сохраняйте его во время выполнения клиента.

Answer 1

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

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

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

Answer 2

Относящиеся к этому вопросу:

Максимальное количество сокетов в Java

Если вы беспокоитесь о превышении максимального количества сокетов, которые могут быть открыты (я полагаю, что это крайне маловероятно в вашем случае), вы можете создать обходной путь, где вы используете TCP для первоначального установления соединения, отправьте клиенту UID (уникальный идентификатор, 64-битный тип unsigned long long должен быть достаточным), а затем закройте соединение TCP. Заполните и сохраните структуру (или объект Class в вашем случае), детализирующую детали соединения (IP-адрес, код уникального идентификатора), а затем дождитесь получения пакетов, отправленных через UDP (протокол пользовательских дейтаграмм, альтернатива TCP). Если вы решите использовать UDP, имейте в виду, что вам потребуется реализовать средство переупорядочения пакетов, чтобы восстановить поток байтов (сериализация) и механизм повторной отправки пакетов данных, если они как-то не поступают (восстановление потери пакетов) .

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