Ладно, если исчерпание порта tcp / ip относится только к клиентской части (что определяется лимитом в 64 КБ на клиента на порт сервера), то почему существует реальная проблема исчерпания портов на серверах? Вы по-прежнему можете использовать все значения кортежа - возможно, мой номер 64k неверен, но существует жесткое ограничение на количество комбинаций, которые может содержать кортеж. Когда у вас заканчиваются комбинации, если вы не используете повторно адрес, у вас закончатся адреса (действительно, уникальный кортеж), чтобы назначить входящее соединение, и соединение будет отклонено.

овать изэтот сокет учебник:

Розетки бывают двух основных вкусов. Активный сокет подключен к удаленному активному сокету через открытое соединение для передачи данных ... Пассивный сокет не подключен, а ожидает входящее соединение, которое порождает новый активный сокет после установления соединения ...

Каждый порт может иметь один пассивный сокет, связанный с ним, ожидающий входящие соединения, и несколько активных сокетов, каждый из которых соответствует открытому соединению на порту. Это как если бы фабричный рабочий ждал прибытия новых сообщений (он представляет пассивный сокет), и когда одно сообщение приходит от нового отправителя, он инициирует с ними переписку (соединение), делегируя кому-то еще (активный сокет) фактически прочитать пакет и ответить отправителю, если это необходимо. Это позволяет работнику фабрики свободно принимать новые пакеты. ...

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

Что я не понял, так это: предположим, что есть входящее соединение с портом, и отправитель хочет отправлять небольшие данные каждые 20 минут. Если активный сокет закрывает соединение при отсутствии оставшихся байтов, должен ли отправитель повторно подключаться к порту каждый раз, когда он хочет отправить данные? Как мы можем сохранить некогда установленную связь в течение более длительного времени? Можете ли вы сказать мне, что мне здесь не хватает?

Мой второй вопрос: кто определяет предел одновременно работающих активных сокетов?

 SRM15 янв. 2011 г., 00:10
Нет проблем, я просто хотел убедиться, что вы понимаете, что вы должны явно закрыть сокет. Это может избавить вас от головной боли, когда вы царапаете голову, пытаясь понять, почему сокет не закрылся :).
 SRM14 янв. 2011 г., 23:58
Вы перефразируете эту статью и берете фрагменты из разных разделов статьи. Контексты разные. В последнем разделе автор объясняет свою программу. Сокеты не работают так по умолчанию, фактически, если вы забудете закрыть сокет, плохие вещи могут и произойдут. Сокет не закрывается автоматически при получении последнего байта.
 aslisabanci15 янв. 2011 г., 00:21
:] Хорошо спасибо.
 aslisabanci15 янв. 2011 г., 00:06
Хорошо, я подумал, что это конвенция, и просто спросил, что мне здесь не хватает. Я новичок в понятиях, и поэтому я хочу подвергнуть сомнению все, что мне трудно понять.

Ответы на вопрос(3)

Решение Вопроса

времени, чтобы поддерживать соединение. Формат KEEPALIVE зависит от протокола. Он может быть таким же маленьким, как один NULL в сегменте данных TCP.

Что касается второго вопроса ... это зависит от ввода / вывода. Если он блокирует ввод-вывод, вам нужно только определенное количество потоков, запущенных на вашем компьютере, поэтому у вас не будет много клиентов. Если это не блокирует, у вас может быть намного больше клиентов. Языки программирования должны поддерживать как блокирующий, так и неблокирующий ввод / вывод. (Я точно знаю, что это делает Java.)

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

 SRM15 янв. 2011 г., 00:04
На самом деле, если у вас будет много клиентов, и каждый запрос будет быстрым (20 секунд, как вы сказали), тогда лучше использовать шаблон типа запрос / ответ. У вас есть только доступные порты 64 КБ, что означает, что только IP-сокеты могут быть приняты на IP до того, как вы исчерпаете порт, если эти сокеты не закрыты. Это действительно зависит от вашего приложения, хотя. Например, если вы пишете MMO, вам нужны постоянные соединения. Если вы пишете веб-сервер, хотя вам не понадобятся (и будут стараться избегать) постоянные соединения (если вы не используете HTML5, но это совсем другая история).
 SRM15 янв. 2011 г., 00:21
Вы можете принять только до 64 тыс. Соединенийодновременно так что до тех пор, пока некоторые клиенты перестают работать, вы не достигнете исчерпания порта. Кроме того, только пассивные сокеты могут принимать, и вы можете иметь только один пассивный сокет, связанный с парой ip / port, так что вы можете прослушивать только один сокет, но многие сокеты могут подключаться.
 ktm512415 янв. 2011 г., 00:07
С точки зрения клиента, простая поддержка активности на одном сервере не требует много работы. Вы, вероятно, уже отправляете полдюжины сообщений активности, когда вы подключены к Интернету. С точки зрения сервера, было бы полезно сохранить как минимум количество сокетов в своем списке сокетов, чтобы повысить производительность ввода-вывода. Если между передачей данных будет ждать 20 минут, я буду каждый раз создавать новое соединение. Это незначительно для клиента, но не для сервера.
 SRM15 янв. 2011 г., 06:43
Ах, да, то, что вы сказали, абсолютно правильно. Вот где механизм очереди и пул потоков пригодятся. Вы также можете использовать вариант шаблона команды таким образом, когда ваши обработчики команд являются обработчиками ответов, а ваш шаблон команд реализован с использованием пула потоков.
 aslisabanci14 янв. 2011 г., 23:58
Таким образом, непрерывная отправка этих пакетов поддержки активности в течение 20 минут - более дешевая операция, чем повторное установление соединения каждый раз? Каковы будут преимущества поддержания соединения в активном состоянии, помимо избежания накладных расходов при повторном соединении?

Да, когда сокет закрыт, вы должны открыть его, чтобы возобновить связь.

Второй вопрос: вы делаете. Если вы хотите, вы можете создать 64k подключений к вашему серверу и страдать от истощения портов (я не рекомендую этого). Как указано в ktm5124, все зависит от вашего приложения. Существует несколько различных способов сделать ваш сервер масштабируемым, включая использование асинхронного ввода-вывода и / или пула потоков для обработки клиентских запросов.

 onmyway13302 мая 2013 г., 13:19
Пожалуйста, посмотрите ответ Уиллаstackoverflow.com/a/2332756/1418457 может быть, вы неправильно поняли что-то о TCP
 SRM02 мая 2013 г., 20:59
Ладно, если исчерпание порта tcp / ip относится только к клиентской части (что определяется лимитом в 64 КБ на клиента на порт сервера), то почему существует реальная проблема исчерпания портов на серверах? Вы по-прежнему можете использовать все значения кортежа - возможно, мой номер 64k неверен, но существует жесткое ограничение на количество комбинаций, которые может содержать кортеж. Когда у вас заканчиваются комбинации, если вы не используете повторно адрес, у вас закончатся адреса (действительно, уникальный кортеж), чтобы назначить входящее соединение, и соединение будет отклонено.

не путайте фактические пакеты, отправленные реализацией TCP / IP по сети, и взаимодействие между вашей программой и библиотекой, реализующей TCP / IP.

Сокет - это просто абстракция, представленная вашей программе реализацией TCP / IP (библиотека или ОС ядра). Вы можете визуализировать сокет как соединение с каналом (localIP: port-remoteIP: port). Ваша программа открывает сокет, передает данные через сокет и может закрыть сокет, если он больше не нужен для освобождения ресурсов. Это нормальный поток. Однако реализация TCP / IP может закрывать сокет по своим собственным уважительным причинам. Некоторые из этих причин: отключение кабеля доступа к сети, ошибки сетевой маршрутизации, отключение сервера и т. Д. Таким образом, ваша программа может обнаружить сокет tcp / ip закрытым, даже если он не закрыл его.

Теперь ваш первый вопрос: что мне делать, если моя программа отправляет небольшие сегменты данных с длинной паузой между ними. Ответ: зависит от того, сколько длится пауза и какая программа слушает вас на другой стороне. Большинство реализаций TCP / IP имеют представление о времени ожидания соединения, чтобы предоставить вам абстракции надежного соединения в реальных ненадежных сетях. Таким образом, если ваша программа сделает паузу дольше, чем время ожидания tcp / ip, вы обнаружите, что ваш сокет был закрыт библиотекой, и вам нужно будет снова открыть сокет. Это также может привести к тому, что вы снова начнете общение, это зависит от программы, которая вас прослушивает на другой стороне канала соединения tcp / ip.

Есть способы увеличить время ожидания tcp / ip и сохранить его живым. Это может быть сделано как часть конфигурации сети, конфигурации программного обеспечения сервера на другом конце или если вы явно просите оставить сокет открытым, установив параметры KEEPALIVE в вызове библиотеки tcp / ip. Будет ли это все еще открыто или нет, зависит. Полная информация о том, как tcp / ip будет держать сокет открытым, не должна смущать вас, поскольку это не имеет никакого отношения к вашему коду. TCP / IP имеет множество настроек и различных тайм-аутов, чтобы обеспечить вашей программе иллюзию стабильного надежного соединения. Хорошая часть - все это скрыто от кода вашей программы, если вы не злоупотребляете им. Держите паузу менее нескольких секунд :) Один набор настроек времени ожидания может хорошо работать для небольших приложений в надежной локальной сети и не будет работать для приложений с высокой нагрузкой или через межконтинентальное соединение. Каждая конкретная ситуация имеет свое собственное решение, часто не просто одно.

В этом конкретном вопросе «отправлять небольшие данные каждые 20 минут» я бы посоветовал вам закрыть и открыть сокетное соединение для каждого сообщения. Время открытия одного меньше секунды и не должно влиять на ваше общение. Взамен вы получаете меньше сложности в вашем протоколе связи. Приемник всегда запускается заново при новом соединении через сокет, и обе системы могут пользоваться бесплатными ресурсами для связи tcp / ip в течение всех 20 минут, когда вам это не нужно.

Ваш ответ на вопрос