Необходимость синхронизации и гонки

Пренебрежение вопросами синхронизации в многопоточной системе может привести к неправильному решению задачи или даже к краху системы.

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

20. Критические секции и блокирующие переменные

Критическая секция — это часть программы, результат выполнения которой может непредсказуемо меняться, если переменные, относящиеся к этой части программы, изменяются другими потоками в то время, когда выполнение этой части еще не завершено. Критическая секция всегда определяется по отношению к определенным критическим данным, при несогласованном изменении которых могут возникнуть нежелательные эффекты. В предыдущем примере такими критическими данными являлись записи файла базы данных. Во всех потоках, работающих с критическими данными, должна быть определена критическая секция. Заметим, что в разных потоках критическая секция состоит в общем случае из разных последовательностей команд. Чтобы исключить эффект гонок по отношению к критическим данным, необходимо обеспечить, чтобы в каждый момент времени в критической секции, связанной с этими данными, находился только один поток. При этом неважно, находится этот поток в активном или в приостановленном состоянии. Этот прием называют взаимным исключением. Операционная система использует разные способы реализации взаимного исключения. Некоторые способы пригодны для взаимного исключения при вхождении в критическую секцию только потоков одного процесса, в то время как другие могут обеспечить взаимное исключение и для потоков разных процессов. Самый простой и в то же время самый неэффективный способ обеспечения взаимного исключения состоит в том, что операционная система позволяет потоку запрещать любые прерывания на время его нахождения в критической секции. Однако этот способ практически не применяется, так как опасно доверять управление системой пользовательскому потоку — он может надолго занять Процессор, а при крахе потока в критической секции крах потерпит вся система, потому что прерывания никогда не будут разрешены. ^ Блокирующие переменные Для синхронизации потоков одного процесса прикладной программист может использовать глобальные блокирующие переменные. С этими переменными, к которым все потоки процесса имеют прямой доступ, программист работает, не обращаясь к системным вызовам ОС. Блокирующие переменные могут использоваться не только при доступе к разделяемым данным, но и при доступе к разделяемым ресурсам любого вида. Если все потоки написаны с учетом вышеописанных соглашений, то взаимное исключение гарантируется. При этом потоки могут быть прерваны операционной системой в любой момент и в любом месте, в том числе в критической секции. Однако следует заметить, что одно ограничение на прерывания все же имеется. Нельзя прерывать поток между выполнением операций проверки и установки блокирующей переменной. Поясним это. Пусть в результате проверки переменной поток определил, что ресурс свободен, но сразу после этого, не успев установить переменную в 0, был прерван. За время его приостановки другой поток занял ресурс, вошел в свою критическую секцию, но также был прерван, не завершив работы с разделяемым ресурсом. Когда управление было возвращено первому потоку, он, считая ресурс свободным, установил признак занятости и начал выполнять свою критическую секцию. Таким образом, был нарушен принцип взаимного исключения, что потенциально может привести к нежелательным I последствиям. Во избежание таких ситуаций в системе команд многих компьютеров предусмотрена единая, неделимая команда анализа и присвоения значения логической переменной (например, команды ВТС, BTR и BTS процессора Pentium). При отсутствии такой команды в процессоре соответствующие действия должны реализовываться специальными системными примитивами¹, которые бы запрещали прерывания на протяжении всей операции проверки и установки. Реализация взаимного исключения описанным выше способом имеет существенный недостаток: в течение времени, когда один поток находится в критической секции, другой поток, которому требуется тот же ресурс, получив доступ к процессору, будет непрерывно опрашивать блокирующую переменную, бесполезно тратя выделяемое ему процессорное время, которое могло бы быть использовано для выполнения какого-нибудь другого потока. Для устранения этого недостатка во многих ОС предусматриваются специальные системные вызовы для работы с критическими секциями.

21.Семафоры и Тупики

Обобщением блокирующих переменных являются так называемые семафоры Дийкстры. Вместо двоичных переменных Дийкстра (Dijkstra) предложил использовать переменные, которые могут принимать целые неотрицательные значения. Такие переменные, используемые для синхронизации вычислительных процессов, получили название семафоров. Для работы с семафорами вводятся два примитива, традиционно обозначаемых Р и V. Пусть переменная S представляет собой семафор. Тогда действия V(S) и P(S) определяются следующим образом.

• V(S): переменная S увеличивается на 1 единым действием. Выборка, наращивание и запоминание не могут быть прерваны. К переменной S нет доступа другим потокам во время выполнения этой операции.

• P(S): уменьшение S на 1, если это возможно. Если S=0 и невозможно уменьшить S, оставаясь в области целых неотрицательных значений, то в этом случае поток, вызывающий операцию Р, ждет, пока это уменьшение станет возможным. Успешная проверка и уменьшение также являются неделимой операцией.

Никакие прерывания во время выполнения примитивов V и Р недопустимы. В частном случае, когда семафор S может принимать только значения 0 и 1, он превращается в блокирующую переменную, которую по этой причине часто называют двоичным семафором. Операция Р заключает в себе потенциальную возможность перехода потока, который ее выполняет, в состояние ожидания, в то время как операция V может при некоторых обстоятельствах активизировать другой поток, приостановленный операцией Р. Рассмотрим использование семафоров на классическом примере взаимодействия двух выполняющихся в режиме мультипрограммирования потоков, один из которых пишет данные в буферный пул, а другой считывает их из буферного пула. Пусть буферный пул состоит из N буферов, каждый из которых может содержать одну запись. В общем случае поток-писатель и поток-читатель могут иметь различные скорости и обращаться к буферному пулу с переменой интенсивностью. В один период скорость записи может превышать скорость чтения, в другой — наоборот. Для правильной совместной работы поток-писатель должен приостанавливаться, когда все буферы оказываются занятыми, и активизироваться при освобождении хотя бы одного буфера. Напротив, поток-читатель должен приостанавливаться, когда все буферы пусты, и активизироваться при появлении хотя бы одной записи. Введем два семафора: е — число пустых буферов, и f — число заполненных буферов, причем в исходном состоянии е = N, a f = 0. Тогда работа потоков с общим буферным пулом может быть описана следующим образом (рис. 4.20). Поток-писатель прежде всего выполняет операцию Р(е), с помощью которой он проверяет, имеются ли в буферном пуле незаполненные буферы. В соответствии с семантикой операции Р, если семафор е равен 0 (то есть свободных буферов в данный момент нет), то поток-писатель переходит в состояние ожидания. Если же значением е является положительное число, то он уменьшает число свободных буферов, записывает данные в очередной свободный буфер и после этого наращивает число занятых буферов операцией V(f). Поток-читатель действует аналогичным образом, с той разницей, что он начинает работу с проверки наличия заполненных буферов, а после чтения данных наращивает количество свободных буферов. Рис. 4.20. Использование семафоров для синхронизации потоков В данном случае предпочтительнее использовать семафоры вместо блокирующих переменных. Действительно, критическим ресурсом здесь является буферный пул, который может быть представлен как набор идентичных ресурсов — отдельных буферов, а значит, с буферным пулом могут работать сразу несколько потоков, и именно столько, сколько буферов в нем содержится. Использование двоичной переменной не позволяет организовать доступ к критическому ресурсу более чем одному потоку. Семафор же решает задачу синхронизации более гибко, допуская к разделяемому пулу ресурсов заданное количество потоков. Так, в нашем примере с буферным пулом могут работать максимум N потоков, часть из которых может быть «писателями», а часть — «читателями».

если средствами синхронизации пользоваться неосторожно, то могут возникнуть непредвиденные затруднения. Предположим, что несколько процессов конкурируют за обладание конечным числом ресурсов. Если запрашиваемый процессом ресурс недоступен, процесс переходит в состояние ожидания. В случае если  требуемый ресурс удерживается другим ожидающим процессом, то  первый процесс не сможет сменить свое состояние. Такая ситуация называется тупиком.  Говорят, что в мультипрограммной системе процесс находится в состоянии тупика, дедлока (deadlock) или клинча, если он ожидает события, которое никогда не произойдет.  Системная тупиковая ситуация или зависание системы является следствием того, что один или более процессов находятся в состоянии тупика.

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

                                                               Рис. 7.1. Пример тупиковой ситуации.

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

22.Синхронизирующие объекты ОС.Сигналы.

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

Примерами таких синхронизирующих объектов ОС являются системные семафоры, мьютексы, события, таймеры и другие — их набор зависит от конкретной ОС, которая создает эти объекты по запросам процессов. Чтобы процессы могли разделять синхронизирующие объекты, в разных ОС используются разные методы. Некоторые ОС возвращают указатель на объект. Этот указатель может быть доступен всем родственным процессам, наследующим характеристики общего родительского процесса. В других ОС процессы в запросах на создание объектов синхронизации указывают имена, которые должны быть им присвоены. Далее эти имена используются разными процессами для манипуляций объектами синхронизации. В таком случае работа с синхронизирующими объектами подобна работе с файлами. Их можно создавать, открывать, закрывать, уничтожать.

Кроме того, для синхронизации могут быть использованы такие «обычные» объекты ОС, как файлы, процессы и потоки. Все эти объекты могут находиться в двух состояниях: сигнальном и несигнальном — свободном. Для каждого объекта смысл, вкладываемый в понятие «сигнальное состояние», зависит от типа объекта. Так, например, поток переходит в сигнальное состояние тогда, когда он завершается. Процесс переходит в сигнальное состояние тогда, когда завершаются все его потоки. Файл переходит в сигнальное состояние в том случае, когда завершается операция ввода-вывода для этого файла. Для остальных объектов сигнальное состояние устанавливается в результате выполнения специальных системных вызовов. Приостановка и активизация потоков осуществляются в зависимости от состояния синхронизирующих объектов ОС.

Потоки с помощью специального системного вызова сообщают операционной системе о том, что они хотят синхронизировать свое выполнение с состоянием некоторого объекта. Будем далее называть этот системный вызов Wait(X), где X — указатель на объект синхронизации. Системный вызов, с помощью которого поток может перевести объект синхронизации в сигнальное состояние, назовем Set(X).

Поток, выполнивший системный вызов Wait(X), переводится операционной системой в состояние ожидания до тех пор, пока объект X не перейдет в сигнальное состояние. Примерами системных вызовов типа Wait ( ) и Set ( ) являются вызовы WaitForSingleObject( ) и SetEvent( )в Windows NT, DosSemWait( ) и DosSemSet( )в OS/2, sleep( )и wakeup( ) в UNIX.

Поток может ожидать установки сигнального состояния не одного объекта, а нескольких. При этом поток может попросить ОС активизировать его при установке либо одного из указанных объектов, либо всех объектов. Поток может в качестве аргумента системного вызова Wait( ) указать также максимальное время, которое он будет ожидать перехода объекта в сигнальное состояние, после чего ОС должна его активизировать в любом случае. Может случиться, что установки некоторого объекта в сигнальное состояние ожидают сразу несколько потоков. В зависимости от объекта синхронизации в состояние готовности могут переводиться либо все ожидающие это событие потоки, либо один из них.

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

Примером асинхронного сигнала является сигнал с терминала. Во многих ОС предусматривается оперативное снятие процесса с выполнения. Для этого пользователь может нажать некоторую комбинацию клавиш (Ctrl+C, Ctrl+Break), в результате чего ОС вырабатывает сигнал и направляет его активному процессу. Сигнал может поступить в любой момент выполнения процесса (то есть он является асинхронным), требуя от процесса немедленного завершения работы. В данном случае реакцией на сигнал является безусловное завершение процесса.

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

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

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

23. Этапы создания сайта

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

2. Разработка дизайна и архитектуры проекта Работа над дизайном сайта предполагает следующие стадии:

• Анализ требований пользовательского интерфейса.

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

• Разработка концепции дизайна.

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

• Одобрение дизайна.

• Стадия предполагает согласование и внесение необходимых корректив в первоначальную концепцию дизайна проекта.

• Результатом работы на этапе разработки дизайна и архитектуры проекта станут эскизы всех типовых страниц веб-сайта.

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

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

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

24.Структура гипертекстового документа,ипс теги и атрибуты ,указать порядок вложения тегов

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

Для создания гипертекстовых документов используется специальный язык - язык гипертекстовой разметки

HTML операторы, которые дают инструкции браузеру, что и как отображать, называют тэгами (tag). Вся информация о форматировании документа сосредоточена между знаками "<" и ">". Именно такой фрагмент называется тэгом, а значки метками. Большинство HTML-меток парные, то есть на каждую открывающую метку вида <tag> есть закрывающая метка вида </tag> с тем же именем, но с добавлением "/". Многие метки, помимо имени, могут содержать атрибуты - элементы, дающие дополнительную информацию о том, как браузер должен обработать текущую метку. 

• <html>  . . . . . </html> - первая метка должна открывать HTML-документ, вторая - завершать его;

• <head>  . . . . . </head> - эта пара меток указывает на начало и конец заголовка документа. Помимо наименования документа, в этот раздел может включаться множество служебной информации;

• <title>  . . . . . </title> - все, что расположено между этими метками толкуется браузером как название документа и отображается в заголовке окна браузера;

• <body> . . . . . </body> - эта пара меток указывает на начало и конец тела HTML-документа, определяющее содержание документа.

<HTML> <HEAD> <TITLE> ... название документа (отображается в заголовке окна браузера) ... </TITLE> .............................................................................

..... служебная информация (необязательно) .....

.............................................................................

</HEAD> <BODY> ..........................................................................................

..... текст документа (отображается в окне браузера) .....

..........................................................................................

</BODY> </HTML>

25.Структура файла разметки кадров(фреймовая)…

ПРЕДСТАВЛЕНИЕ ДАННЫХ С ПОМОЩЬЮ ФРЕЙМОВ

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

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

ОПИСАНИЕ ФРЕЙМОВОЙ СТРУКТУРЫ

Фреймовая структура определяет только способ организации экрана с фреймами и указывает, где находится начальное содержимое каждого фрейма. Для всех фреймов должны быть заданы адреса, описывающие местонахождения данных. Как правило, на странице с фреймовой структурой нет содержимого фреймов. Такая страница обычно невелика, описывает только фреймовую структуру экрана. Для описания структуры фреймов используются теги <FRAMESET>, <FRAME>, <NOFRAMES>.

Тег <FRAMESET>

Фреймы определяются в структуре, называемой FRAMESET, которая используется для страниц, содержащих фреймы, вместо раздела BODY обычного документа. Web-страницы, составленные из фреймов, не могут содержать раздела BODY, Страницы с разделом BODY не могут содержать фреймы. Теги <FRAMESET> и </FRAMESET> обрамляют каждый блок определения фреймов. Внутри него могут содержаться только теги <FRAMESET> и <FRAME>.

Тег <FRAMESET> имеет два параметра ROWS (строки) и COLS (столбцы). В общем случае тег <FRAMESET> записывается в виде:

<FRAMESET ROWS="список значений" COLS="список значений">

Можно определить значения для ROWS или COLS или обоих вместе. Необходимо определить два значения хотя бы одного из этих двух параметров. Если другой параметр опущен, то его значение принимается равным 100%. Нельзя определить <FRAMESET>, состоящий из одного фрейма.

Список значений параметров ROWS и COLS представляет собой разделенный запятыми список значений, которые могут задаваться:

• в пикселях,

• в процентах,

• в относительных единицах

Число строк или столбцов определяется числом значений в соответствующем списке.

26. Прикладной протокол HTTP

HTTP (англ. HyperText Transfer Prоtocоl — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

Протокол HTTP (Hyper Text Transfer Protocol) обеспечивает передачу с удаленных серверов на локальный компьютер документов, содержащих код разметки гипертекста, написанный на языке HTML или XML, то есть веб-страниц. Данный прикладной протокол ориентирован прежде всего на предоставление информации программам просмотра веб-страниц, веб-браузерам, наиболее известными из которых являются такие приложения, как Microsoft Internet Explorer и Netscape Communicator. Именно с использованием протокола HTTP организуется отправка запросов удаленным http-серверам сети Интернет и обработка их откликов; помимо этого HTTP позволяет использовать для вызова ресурсов Всемирной сети адреса стандарта доменной системы имен (DNS, Domain Name System), то есть обозначения, называемые URL (Uniform Resource Locator) вида http:/ /www.domain.zone/page (l).

Преимущества

Простота

Протокол настолько прост в реализации, что позволяет с лёгкостью создавать клиентские приложения.

Расширяемость

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

Распространённость

При выборе протокола HTTP для решения конкретных задач немаловажным фактором является его распространённость. Как следствие, это обилие различной документации по протоколу на многих языках мира, включение удобных в использовании средств разработки в популярные IDE, поддержка протокола в качестве клиента многими программами и обширный выбор среди хостинговых компаний с серверами HTTP.

Недостатки и проблемы

Отсутствие «навигации»

Отсутствие поддержки распределённости

Протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вовсе не приниматься в расчёт. Но в промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается непригоден. В 1998 году W3C предложил альтернативный протокол HTTP-NG (англ. HTTP Next Generation) для полной замены устаревшего с акцентированием внимания именно на этой области^[2]. Идею его необходимости поддержали крупные специалисты по распределённым вычислениям, но данный протокол до сих пор находится на стадии разработки.

27. Прикладной протокол FTP

— стандартный протокол, предназначенный для передачи файлов по TCP-сетям (например, Интернет). FTP часто используется для загрузки сетевых страниц и других документов с частного устройства разработки на открытые сервера хостинга.

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

Как следует из названия, протокол FTP (File Transfer Protocol) предназначен для передачи файлов через Интернет. Именно на базе этого протокола реализованы процедуры загрузки и выгрузки файлов на удаленных узлах Всемирной Сети. FTP позволяет переносить с машины па машину не только файлы, но и целые папки, включающие поддиректории на любую глубину вложений. Осуществляется это путем обращения к системе команд FTP, описывающих ряд встроенных функций данного протокола.