Что значит порт time wait
Печенюшка
Протокол TCP: состояние TIME-WAIT
При использовании утилиты TCP View от Sysinternals или консольной команды netstat мы часто видим несколько непонятных состояний TCP-соединений. Если слова ESTABLISHED и LISTENING в состоянии соединения не вызывают вопросов, то что такое TIME_WAIT? Ожидание? Ожидание чего?…
Ответ на этот вопрос в полной мере дал мне сегодня Яндекс.
Состояние TIME-WAIT наступает в ходе разрыва соединения. Для разрыва TCP-соединения нужно обычно обменяться четырьмя сегментами, как показано на рисунке.
На рисунке показано соединение между двумя приложениями, работающими на хостах 1 и 2. Приложение на хосте 1 закрывает свою сторону соединения, при этом TCP посылает сегмент FIN хосту 2. Хост 2 подтверждает FIN сегментом АСК и доставляет FIN приложению в виде признака конца файла EOF (предполагается, что у приложения есть незавершенная операция чтения). Позже приложение на хосте 2 закрывает свою сторону соединения, посылая FIN хосту 1, который отвечает сегментом АСК.
В этот момент хост 2 окончательно закрывает соединение и освобождает ресурсы. С точки зрения хоста 2, соединения больше не существует. Однако хост 1 закрывает соединение, а переходит в состояние TIME-WAIT и остается в нем в течение двух максимальных продолжительностей существования сегмента (2MSL maximum segment lifetime).
Состояние TIME-WAIT служит двум целям:
— не дать соединению пропасть при потере последнего АСК, посланного активной стороной, в результате чего другая сторона повторно посылает FIN;
— дать время исчезнуть «заблудившимся сегментам», принадлежащим этому соединению.
3 необычных кейса о сетевой подсистеме Linux
В этой статье представлены три небольшие истории, которые произошли в нашей практике: в разное время и в разных проектах. Объединяет их то, что они связаны с сетевой подсистемой Linux (Reverse Path Filter, TIME_WAIT, multicast) и иллюстрируют, как глубоко зачастую приходится анализировать инцидент, с которым сталкиваешься впервые, чтобы решить возникшую проблему… и, конечно, какую радость можно испытать в результате полученного решения.
История первая: о Reverse Path Filter
Клиент с большой корпоративной сетью решил пропускать часть своего интернет-трафика через единый корпоративный файрвол, расположенный за маршрутизатором центрального подразделения. С помощью iproute2 трафик, уходящий в интернет, был направлен в центральное подразделение, где уже было настроено несколько таблиц маршрутизации. Добавив дополнительную таблицу маршрутизации и настроив в ней маршруты перенаправления на файрвол, мы включили перенаправление трафика из других филиалов и… трафик не пошел.
Схема прохождения трафика через таблицы и цепочки Netfilter
Начали выяснять, почему не работает настроенная маршрутизация. На входящем туннельном интерфейсе маршрутизатора трафик обнаруживался:
Однако на исходящем интерфейсе пакетов не было. Стало ясно, что фильтруются они на маршрутизаторе, однако явно установленных правил отбрасывания пакетов в iptables не было. Поэтому мы начали последовательно, по мере прохождения трафика, устанавливать правила, отбрасывающие наши пакеты и после установки смотреть счетчики:
Проверили последовательно nat PREROUTING, mangle PREROUTING. В mangle FORWARD счетчик не увеличивался, а значит — пакеты теряются на этапе маршрутизации. Проверив снова маршруты и правила, начали изучать, что именно происходит на этом этапе.
В ядре Linux для каждого интерфейса по умолчанию включен параметр Reverse Path Filtering ( rp_filter ). В случае, когда вы используете сложную, асимметричную маршрутизацию и пакет с ответом будет возвращаться в источник не тем маршрутом, которым пришел пакет-запрос, Linux будет отфильтровывать такой трафик. Для решения этой задачи необходимо отключить Reverse Path Filtering для всех ваших сетевых устройств, принимающих участие в маршрутизации. Чуть ниже простой и быстрый способ сделать это для всех имеющихся у вас сетевых устройств:
Возвращаясь к кейсу, мы решили проблему, отключив Reverse Path Filter для интерфейса tap0 и теперь хорошим тоном на маршрутизаторах считаем отключение rp_filter для всех устройств, принимающих участие в асимметричном роутинге.
История вторая: о TIME_WAIT
В обслуживаемом нами высоконагруженном веб-проекте возникла необычная проблема: от 1 до 3 процентов пользователей не могли получить доступ к сайту. При изучении проблемы мы выяснили, что недоступность никак не коррелировала с загрузкой любых системных ресурсов (диск, память, сеть и т.д.), не зависела от местоположения пользователя или его оператора связи. Единственное, что объединяло всех пользователей, которые испытывали проблемы, — они выходили в интернет через NAT.
Механизм закрытия TCP-соединения
И выполните команду:
История третья: об OSPF и мультикастовом трафике
Обслуживаемая корпоративная сеть была построена на базе tinc VPN и прилегающими к ней лучами IPSec и OVPN-соединений. Для маршрутизации всего этого адресного пространства L3 мы использовали OSPF. На одном из узлов, куда агрегировалось большое количество каналов, мы обнаружили, что небольшая часть сетей, несмотря на верную конфигурацию OSPF, периодически пропадает из таблицы маршрутов на этом узле.
Упрощенное устройство VPN-сети, используемой в описываемом проекте
В первую очередь проверили связь с маршрутизаторами проблемных сетей. Связь была стабильной:
Продиагностировав OSPF, мы удивились еще больше. На узле, где наблюдались проблемы, маршрутизаторы проблемных сетей отсутствовали в списке соседей. На другой стороне проблемный маршрутизатор в списке соседей присутствовал:
Следующим этапом исключили возможные проблемы с доставкой ospf hello от 172.24.0.1. Запросы от него приходили, а вот ответы — не уходили:
Заключение
Какой бы сложной ни была проблема, она всегда решаема и зачастую — с помощью изучения документации. Буду рад увидеть в комментариях описание вашего опыта поиска решения сложных и необычных проблем.
Устранение проблем нехватки портов
Протоколы TCP и UDP работают на основе номеров портов, используемых для установления подключения. Любому приложению или службе, необходимой для установления подключения TCP/UDP, потребуется порт на его стороне.
Существует два типа портов:
Клиенты при подключении к приложению или службе будут использовать эфемерный порт из его машины для подключения к известному порту, определенному для этого приложения или службы. Браузер на клиентской машине будет использовать эфемерный порт для подключения к https://www.microsoft.com порту 443.
В сценарии, в котором один и тот же браузер создает много подключений к нескольким веб-сайтам, для любого нового подключения, которое пытается использовать браузер, используется эфемерный порт. Через некоторое время вы заметите, что подключения начнут сбой и одна высокая возможность для этого будет потому, что браузер использовал все доступные порты для подключения за пределами и любые новые попытки установить подключение не удастся, так как нет более доступных портов. Когда все порты на компьютере используются, мы используем его как истощение порта.
Динамический диапазон порта по умолчанию для TCP/IP
Чтобы соответствовать рекомендациям управления номерами, заданными в Интернете, Корпорация Майкрософт увеличила динамический диапазон клиентских портов для исходяющих подключений. Новый порт запуска по умолчанию — 49152, а конечный порт по умолчанию — 65535. Это изменение конфигурации более ранних версий Windows, которые использовали диапазон портов по умолчанию от 1025 до 5000.
Динамический диапазон порта можно просмотреть на компьютере с помощью следующих команд сетки:
Диапазон устанавливается отдельно для каждого транспорта (TCP или UDP). Диапазон порта теперь — это диапазон, который имеет отправную точку и конечную точку. Клиенты Корпорации Майкрософт, развертывавшие серверы, работающие Windows Server, могут иметь проблемы, влияющие на связь RPC между серверами, если брандмауэры используются во внутренней сети. В этих ситуациях рекомендуется перенастроить брандмауэры, чтобы разрешить трафик между серверами в динамическом диапазоне портов от 49152 до 65535. Этот диапазон помимо известных портов, используемых службами и приложениями. Или диапазон портов, используемый серверами, может быть изменен на каждом сервере. Этот диапазон можно настроить с помощью команды netsh следующим образом. Вышеуказанная команда задает динамический диапазон порта для TCP.
Порт запуска — это число, а общее число портов — диапазон. Ниже приводится пример команд:
Эти примерные команды устанавливают динамический диапазон портов для запуска в порте 10000 и окончания в порте 10999 (1000 портов). Минимальный диапазон портов, который можно установить, — 255. Минимальный порт запуска, который можно установить, — 1025. Максимальный конечный порт (в зависимости от настраиваемого диапазона) не может превышать 65535. Чтобы повторить поведение Windows Server 2003, используйте 1025 в качестве порта запуска, а затем используйте 3976 в качестве диапазона для TCP и UDP. Это приводит к запуску порта 1025 и конечного порта 5000.
В частности, для исходящие подключения в качестве входящих подключений не потребуется эфемерный порт для приемки подключений.
Так как исходящие подключения начинают сбой, вы увидите много ниже поведения:
Не удается войти в машину с учетными данными домена, однако вход с локальной учетной записью работает. Для регистрации домена потребуется связаться с dc для проверки подлинности, которая снова является исходящие подключения. Если у вас есть набор учетных данных кэша, вход в домен может по-прежнему работать.
Сбои обновления групповой политики:
Недоступными являются файлы:
RDP с пострадавшего сервера не удается:
Любое другое приложение, запущенное на компьютере, начнет выдать ошибки
Перезагрузка сервера позволит решить проблему временно, но все симптомы будут возвращаться через некоторое время.
Если вы подозреваете, что машина находится в состоянии истощения порта:
Попробуйте сделать исходящие подключения. На сервере/компьютере можно получить доступ к удаленной совместной информации или попробовать RDP на другом сервере или telnet на сервере в порту. Если исходящие подключения не удается для всех этих, перейдите к следующему шагу.
Откройте для просмотра событий и в системных журналах и посмотрите события, которые четко указывают текущее состояние:
Event ID 4227
ID события 4231
После изящного закрытия сеанса или внезапного закрытия сеанса через 4 минуты (по умолчанию) порт, используемый для этого процесса или приложения, будет выпущен обратно в доступный пул. В течение 4 минут состояние подключения TCP будет TIME_WAIT состояние. В ситуации, когда вы подозреваете истощение порта, приложение или процесс не смогут освободить все потребляемые порты и останутся в TIME_WAIT состоянии.
Вы также можете CLOSE_WAIT подключений состояния в одном и том же выходе, однако CLOSE_WAIT состояние — это состояние, когда одна сторона одноранговой сети TCP не имеет больше данных для отправки (fin sent), но может получать данные с другого конца. Это состояние не обязательно указывает на исчерпание порта.
Наличие огромных подключений в TIME_WAIT состоянии не всегда указывает на то, что сервер в настоящее время находится вне портов, если первые две точки не будут проверены. Наличие многких подключений TIME_WAIT указывает на то, что процесс создает большое количество подключений TCP и в конечном итоге может привести к исчерпанию порта.
До 10/2016 netstat был неточным. Исправления для netstat, от порта до 2012 R2, позволили Netstat.exe и Get-NetTcpConnection правильно сообщать об использовании порта TCP или UDP в Windows Server 2012 R2. Дополнительные Windows Server 2012 см. в Windows Server 2012 R2: hotfixes ephemeral ports.
Откройте командную подсказку в режиме администрирования и запустите приведенную ниже команду
Откройте файл server.etl с помощью сетевого монитора и в разделе фильтра применяйте фильтр Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND. Status.LENTStatus.Code == 0x209. Вы должны увидеть записи, которые говорят STATUS_TOO_MANY_ADDRESSES. Если вы не найдете записей, сервер по-прежнему не выходит из портов. Если их найти, можно подтвердить, что сервер находится под истощением порта.
Устранение неполадок в истощении порта
Главное — определить, какой процесс или приложение использует все порты. Ниже приведены некоторые средства, которые можно использовать для изоляции одного процесса
Метод 1
Большинство утечек портов вызваны процессами пользовательского режима, которые неправильно закрывают порты, когда произошла ошибка. В портах уровня пользователя (на самом деле розетки) обрабатываются. И TaskManager, и ProcessExplorer могут отображать подсчеты обработки, что позволяет определить, какой процесс потребляет все порты.
Для Windows 7 и Windows Server 2008 R2 можно обновить версию PowerShell, чтобы включить вышеуказанный список.
Метод 2
Если метод 1 не помогает определить процесс (до Windows 10 и Windows Server 2012 R2), то посмотрите на диспетчер задач:
Добавьте столбец под названием «ручки» под сведениями и процессами.
Сортировать ручки столбца, чтобы определить процесс с самым большим числом рули. Обычно виновником может быть процесс с ручками более 3000, за исключением таких процессов, как System, lsass.exe, store.exe, sqlsvr.exe.
Если какой-либо другой процесс имеет более высокое число, остановите этот процесс, а затем попробуйте войти с помощью учетных данных домена и узнайте, удастся ли ему это сделать.
Метод 3
Если диспетчер задач не помог вам определить процесс, используйте Обозреватель процессов для изучения проблемы.
Действия по использованию проводника процесса:
Скачайте Explorer процесса и запустите его с повышенными уровнями.
Alt + щелкните заглавную колонку, выберите Выберите столбцыи на вкладке Производительность процесса добавьте количество обработок.
Выберите Представление \ Показать нижнюю области.
Выберите Представление \ Представление нижней области \ Ручки.
Щелкните столбец Ручки для сортировки по этому значению.
Изучите процессы с более высоким количеством обрабатываемой обработки, чем остальные (если вы не можете сделать исходящие подключения более 10 000).
Щелкните, чтобы выделить один из процессов с высоким количеством обработки.
В нижней области окантовки, указанные ниже, являются розетками. (Sockets — это технически обработки файлов).
Некоторые из них являются нормальными, но большое число из них не являются (от сотен до тысяч). Закрой процесс, о чем идет речь. Если это восстанавливает исходящие подключения, то вы еще раз доказали, что это приложение является причиной. Свяжитесь с поставщиком этого приложения.
Наконец, если вышеперечисленные методы не помогли изолировать процесс, предлагаем собрать полную свалку памяти машины в состоянии проблемы. При сбросе будет посвеяно, какой процесс имеет максимальные ручки.
В качестве обходного решения перезагрузка компьютера возвращает его в нормальное состояние и поможет вам решить проблему в настоящее время. Однако при нецелесообразной перезагрузке можно также рассмотреть возможность увеличения количества портов на машине с помощью нижеупомяг.
В этом случае динамический диапазон портов будет начинаться в порту 10000 и заканчивается в порте 10999 (1000 портов). Минимальный диапазон портов, который можно установить, — 255. Минимальный порт запуска, который можно установить, — 1025. Максимальный конечный порт (в зависимости от настраиваемого диапазона) не может превышать 65535.
Обратите внимание, что увеличение динамического диапазона портов является не постоянным решением, а временным. Вам потребуется отслеживать, какие процессы и процессоры потребляют максимальное количество портов и устраняют неполадки с точки зрения этого процесса, чтобы понять, почему он потребляет такое большое количество портов.
Для Windows 7 и Windows Server 2008 R2 можно использовать ниже скрипт для сбора вывода netstat с определенной частотой. Из выходных данных можно увидеть тенденцию использования порта.
Русские Блоги
Состояние протокола 9.TCP-TIME_WAIT
Рисунок 1 Внимательно наблюдайте за окончательным состоянием партии, которая активно закрылась
TIME_WAIT состояние
Тем не менее, MSL не использует количество прыжков, но время. В разных системах размер определения MSL различен: в RFC указано, что MSL = 2 минуты, но в реальной реализации обычно это 30 секунд и 1 минута. Хотя единицей MSL является время, а не прыжки, мы по-прежнему предполагаем, что пакет с максимальным количеством переходов (255) не может существовать в сети более секунд MSL.
Когда протокол TCP входит в состояние TIME_WAIT, он должен оставаться в этом состоянии вдвое больше времени MSL.
Предположим, что соединение A установлено между ip1: port1 и ip2: port2, и соединение A закрывается после отправки данных. Если нет состояния TIME_WAIT, мы немедленно устанавливаем соединение B между ip1: port1 и ip2: port2 (хотя этот тип вещи имеет низкую вероятность, он все еще существует).
К сожалению, соединение A имеет дублированный сегмент TCP, полученный соединением B. Однако соединение B не знает, что этот сегмент TCP является старым сообщением в соединении A, что приведет к ошибке!
Если у вас есть состояние TIME_WAIT, ожидания 2MSL достаточно, чтобы повторные пакеты в соединении A исчезли в сети, с другой стороны, протокол TCP предусматривает, что порт в состоянии TIME_WAIT не может установить новое соединение. Это гарантирует, что при каждом успешном установлении нового соединения дублирующиеся сегменты TCP в старом соединении исчезают.
2. Эффект состояния TIME_WAIT
Если TCP находится в состоянии TIME_WAIT, он будет ожидать 2MSL времени. В течение этого времени локальный порт, определяющий это соединение, не может быть снова использован. Например, есть связь:
Затем для хоста 192.168.80.130 порт 5050 не может быть снова использован в течение 2MSL времени.
Вообще говоря, тот, который активно закрывает клиента, является клиентом. Номер порта, когда клиент устанавливает соединение, автоматически назначается системой. Это не имеет никакого эффекта. Если порт занят, то назначается другой порт.
Однако для сервера используемый им порт является хорошо известным портом (открытый порт). Если он активно закрывает сторону и входит в состояние TIME_WAIT, то сервер не может быть запущен в пределах 2MSL. Если вы начнете снова, вам будет предложено Address already in use ошибка.
Мы используем эксперименты для симуляции активного отключения сервера.
3. Эксперимент
3.1 Экспериментальная процедура
Если мы снова запустим сервер, произойдет ошибка:
Анализ результатов
И наоборот, если клиент также хочет подать заявку на локальный порт в 2MSL, произойдет то же самое. Но, вообще говоря, локальный порт, используемый клиентом, не указывается сам по себе, а автоматически назначается системой, поэтому проблем нет.
Но для сервера, если его известный порт находится в состоянии TIME_WAIT, он не запустится снова. Фактически, Linux теперь предоставляет метод, который может разрешить повторное использование порта, указав опцию сокета SO_REUSEADDR.
Интеллектуальная рекомендация
Tree Дерево отрезков линии】 COGS 2632
Ссылочный блогАвтор:dreaming__ldxИсточник: CSDN Портал последовательности операций 【Название описания】 Последовательность длины n, вес порядкового номера в начале равен 0, есть m операций Поддерживают.
PAT-A-1046 кратчайшее расстояние [префикс и]
The task is really simple: given N exits on a highway which forms a simple cycle, you are supposed to tell the shortest distance between any pair of exits. Input Specification: Each input fi.
Как нарисовать несколько линий ROC на одном графике?
Класс коллекции JAVA
Резюме JAVA-коллекции Один, коллекция 1. Характеристики коллекций: коллекции используются только для хранения объектов, длина коллекции является переменной, и в коллекции могут храниться объекты разны.
MySQL репликация главный-подчиненный + переключатель главный-подчиненный
MySQL репликация главный-подчиненный + переключатель главный-подчиненный 05 января 2018 10:46:35Протрите протирать прыжок Количество просмотров: 5183Более Персональная категория:база данныхЭксплуатаци.
2.7. Состояние TIME_WAIT
2.7. Состояние TIME_WAIT
Без сомнений, самым сложным для понимания аспектом TCP в отношении сетевого программирования является состояние TIME_WAIT (время ожидания). На рис. 2.4 мы видим, что узел, выполняющий активное закрытие, проходит это состояние. Продолжительность этого состояния равна двум MSL (maximum segment lifetime — максимальное время жизни сегмента), иногда этот период называется 2MSL.
В каждой реализации TCP выбирается какое-то значение MSL. Рекомендуемое значение, приведенное в документе RFC 1122 [10], равно 2 мин, хотя Беркли-реализации традиционно использовали значение 30 с. Это означает, что продолжительность состояния TIME_WAIT — от 1 до 4 мин. MSL — это максимальное количество времени, в течение которого дейтаграмма IP может оставаться в сети. Это время ограничено, поскольку каждая дейтаграмма содержит 8-разрядное поле предельного количества прыжков (hop limit) (поле TTL IPv4 на рис. А.1 и поле «Предельное количество транзитных узлов» IPv6 на рис. А.2), максимальное значение которого равно 255. Хотя этот предел ограничивает количество транзитных узлов, а не время пребывания пакета в сети, считается, что пакет с максимальным значением этого предела (которое равно 255) не может существовать в сети более MSL секунд.
Пакеты в объединенных сетях обычно теряются в результате различных аномалий. Маршрутизатор отключается, или нарушается связь между двумя маршрутизаторами, и им требуются секунды или минуты для стабилизации и нахождения альтернативного пути. В течение этого периода времени могут возникать петли маршрутизации (маршрутизатор А отправляет пакеты маршрутизатору В, а маршрутизатор В отправляет их обратно маршрутизатору А), и пакеты теряются в этих петлях. В этот момент, если потерянный пакет — это сегмент TCP, истекает установленное время ожидания отправляющего узла, и он снова передает пакет, и этот заново переданный пакет доходит до конечного места назначения по некоему альтернативному пути. Но если спустя некоторое время (не превосходящее количества секунд MSL после начала передачи потерянного пакета) петля маршрутизации исправляется, пакет, потерянный в петле, отправляется к конечному месту назначения. Начальный пакет называется потерянной копией или дубликатом (lost duplicate), а также блуждающей копией или дубликатом (wandering duplicate). TCP должен обрабатывать эти дублированные пакеты.
Есть две причины существования состояния TIME_WAIT:
? необходимо обеспечить надежность разрыва двустороннего соединения TCP;
? необходимо подождать, когда истечет время жизни в сети старых дублированных сегментов.
Первую причину можно объяснить, рассматривая рис. 2.5 в предположении, что последний сегмент ACK потерян. Сервер еще раз отправит свой последний сегмент FIN, поэтому клиент должен сохранять информацию о своем состоянии, чтобы отправить завершающее подтверждение ACK повторно. Если бы клиент не сохранял информацию о состоянии, он ответил бы серверу сегментом RST (еще один вид сегмента TCP), что сервер интерпретировал бы как ошибку. Если ответственность за корректное завершение двустороннего соединения в обоих направлениях ложится на TCP, он должен правильно обрабатывать потерю любого из четырех сегментов. Этот пример объясняет, почему в состоянии TIME_WAIT остается узел, выполняющий активное закрытие: именно этому узлу может потребоваться повторно передать подтверждение.
Чтобы понять вторую причину, по которой необходимо состояние TIME_WAIT, давайте считать, что у нас имеется соединение между IP-адресом 12.106.32.254, порт 1500 и IP-адресом 206.168.112.219, порт 21. Это соединение закрывается, и спустя некоторое время мы устанавливаем другое соединение между теми же IP-адресами и портами: 12.106.32.254, порт 1500 и 206.168.112.219, порт 21. Последнее соединение называется новым воплощением (incarnation) предыдущего соединения, поскольку IP-адреса и порты те же. TCP должен предотвратить появление старых дубликатов, относящихся к данному соединению, в новом воплощении этого соединения. Чтобы гарантировать это, TCP запрещает установление нового воплощения соединения, которое в данный момент находится в состоянии TIME_WAIT. Поскольку продолжительность состояния TIME_WAIT равна двум MSL, это позволяет удостовериться, что истечет и время жизни пакетов, посланных в одном направлении, и время жизни пакетов, посланных в ответ. Используя это правило, мы гарантируем, что в момент успешного установления соединения TCP время жизни в сети всех старых дубликатов от предыдущих воплощений этого соединения уже истекло.
Из этого правила существует исключение. Реализации, происходящие от Беркли, инициируют новое воплощение соединения, которое в настоящий момент находится в состоянии TIME WAIT, если приходящий сегмент SYN имеет порядковый номер «больше» конечного номера из предыдущего воплощения. На с. 958-959 [128] об этом рассказано более подробно. Для этого требуется, чтобы сервер выполнил активное закрытие, поскольку состояние TIME_WAIT должно существовать на узле, получающем следующий сегмент SYN. Эта возможность используется командой rsh. В документе RFC 1185 [54] рассказывается о некоторых ловушках, которые могут вас подстерегать при этом.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Читайте также
Состояние процесса
Состояние процесса Поле state дескриптора процесса описывает текущее состояние процесса (рис. 3.3). Каждый процесс в системе гарантированно находится в одном из пяти различных состояний. Рис. 3.3. Диаграмма состояний процессаЭти состояния представляются значением одного из
6.2. Состояние
6.2. Состояние Понятие состояния (state) является фундаментальным не только в метамоде-ли языка UML, но и в прикладном системном анализе. Ранее в главе 1 кратко были рассмотрены особенности представления динамических характеристик сложных систем, традиционно используемых для
Начальное состояние
Начальное состояние Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния). В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме
Конечное состояние
Конечное состояние Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный
6.5. Историческое состояние
6.5. Историческое состояние Как было отмечено выше, формализм обычного автомата не позволяет учитывать предысторию в процессе моделирования поведения объектов. Однако функционирование целого ряда систем основано на возможности выхода из отдельных состояний с
7.1. Состояние действия
7.1. Состояние действия Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Состояние действия
Физическое и эмоциональное состояние
Физическое и эмоциональное состояние Казалось бы, очевидная вещь, хорошее физическое и эмоциональное состояние позволяет работать на порядок лучше, меньше уставать, быть более сконцентрированным. Это вроде бы все понимают, и, в то же время, только единицы уделяют этим
Состояние и версия записи
Состояние и версия записи Каждый объект DataRow имеет свойство RowState, которое обозначает текущее состояние или статус записи. Кроме того, каждая запись хранит информацию о четырех разных версиях своего значения. По мере редактирования записи изменяется ее состояние и версия
Статическое состояние
Предыдущее состояние дел
Состояние готовности
Состояние готовности Наконец, нужно гарантировать, что при снятии указателя мыши с пункта меню пользователем в первой текстовой панели не останется «старая» подсказка, а будет отображено некоторое «типовое» сообщение (например: «Ожидание действий пользователя»). В текущем
8.4. Состояние планировщика событий
4.4.1. Состояние гонки
4.4.1. Состояние гонки Предположим, что в программу поступает группа запросов, которые обрабатываются несколькими одновременными потоками. Очередь запросов представлена связанным списком объектов типа struct job.Когда каждый поток завершает свою операцию, он обращается к
Состояние
Состояние Триггер может быть активным (active) или неактивным (inactive). Запускаются только активные триггеры. См. замечания к ALTER TRIGGER по поводу подробностей деактивации