Этот вызов заставляет послать данные, содержащиеся в указанном пользователем буфере, в указанное соединение. Если соединение еще не было открыто, то SEND рассматривается как ошибка. Некоторые реализации могут позволять пользователю сделать вызов SEND и в такой ситуации. В этом случае будет автоматически выполняться команда OPEN. Если вызывающий процесс не уполномочен использовать это соединение, то возвращается ошибка.
Если задан флаг PUSH, данные должны сразу передаваться получателю, и бит PUSH будет установлен в последнем сегменте, созданном из буфера. Если флаг PUSH не установлен, данные могут комбинироваться с данными из последующих команд SEND для эффективности передачи.
Если установлен флаг URGENT, то в сегментах, посланных TCP назначения, будет задан указатель срочности. Получающий TCP будет сигнализировать об условии срочности получающему процессу, если указатель срочности показывает, что данные, предшествующие указателю срочности, не были получены получающим процессом. Назначение срочности состоит в стимуляции получателя к обработке срочных данных и для указания получателю, когда все известные в данный момент срочные данные будут получены. Число раз, которое TCP посылающего пользователя сигнализирует о срочности, не обязательно будет равно числу уведомлений получающего пользователя о присутствии срочных данных.
Если в OPEN не был определен никакой внешний сокет, но соединение установлено (например, потому что прослушиваемое соединение стало определенным в связи с получением внешнего сегмента на локальном соке-те), то обозначенный буфер посылается на подразумеваемый внешний сокет. Пользователи, которые применяют SEND с не указанным внешним сокетом, могут делать это, даже не зная точно адрес внешнего сокета.
Однако если SEND выполняется до того, как был определен внешний сокет, то будет возвращаться ошибка. Пользователи могут применять вызов STATUS для определения статуса соединения. В некоторых реализациях TCP может уведомлять пользователя, когда связывается неопределенный сокет.
Если определяется задержка, то задержка текущего пользователя этого соединения изменяется на новое значение. В простейшей реализации SEND не будет возвращать управление посылающему процессу, пока либо передача не будет завершена, либо не истечет время задержки. Однако этот простой метод может приводить к блокированию (например, обе стороны соединения могут пытаться выполнить SEND, не выполнив ни одной команды RECEIVE) и реализует плохую производительность, поэтому он не рекомендуется. Более сложная и современная реализация будет немедленно возвращать управление, чтобы следующий процесс выполнялся одновременно с сетевым вводом-выводом, и, более того, чтобы реализовать несколько выполняющихся SEND. Несколько SEND обслуживаются в порядке простой очереди, поэтому TCP будет создавать очередь из тех, кого он не может обслужить немедленно.
Здесь неявно предполагается асинхронный интерфейс пользователя, где SEND в дальнейшем вызывает появление некоторого вида SIGNAL (сигнала) или псевдопрерывания от обслуживающего TCP. Альтернативой является немедленный возврат ответа. Например, SEND мог бы немедленно вернуть локальное подтверждение, даже если посланный сегмент не был подтвержден удаленным TCP. Можно было бы оптимистично предполагать конечный успех. Если мы ошиблись, то соединение будет закрыто в любом случае в связи с истечением времени ожидания. В реализациях такого рода (синхронных) все равно будут некоторые асинхронные сигналы, но они будут иметь дело с самим соединением, а не со специфическими сегментами или буферами.
Чтобы процесс различал индикаторы успеха/неудачи для различных SEND, может оказаться удобным возвращать адрес буфера вместе с кодированным ответом на запрос SEND. Сигналы TCP пользователю обсуждаются ниже с указанием информации, которая должна быть возвращена вызывающему процессу.
Эта команда выделяет буфер получения, связанный с указанным соединением. Если этой команде не предшествует команда OPEN, или вызывающий процесс не уполномочен использовать это соединение, возвращается ошибка.
В простейшей реализации управление не будет возвращаться вызывающей программе, пока не заполнится буфер или не произойдет какая-нибудь ошибка, но эта схема существенно подвержена блокированию. Более развитая реализация будет позволять нескольким командам RECEIVE ожидать выполнения одновременно. Они будут выполняться по мере поступления сегментов. Эта стратегия позволяет увеличить пропускную способность за счет более развитой схемы (возможно, асинхронной) уведомления вызывающей программы, что был получен PUSH или заполнен буфер. Если прибывает количество данных, достаточное для заполнения буфера до появления PUSH, флаг PUSH в ответ на RECEIVE задаваться не будет. Буфер будет заполнен таким количеством данных, сколько он может вместить. Если до заполнения буфера появляется PUSH, буфер возвращается частично заполненным и с указанием PUSH.
При наличии срочных данных пользователь будет проинформирован об этом, как только они появятся, с помощью сигнала TCP пользователю. Получающий пользователь должен поэтому находиться в "срочном режиме". Если установлен флаг URGENT, остаются дополнительные срочные данные. Если флаг URGENT сброшен, то этот вызов RECEIVE вернул все срочные данные, и пользователь может теперь покинуть "срочный режим". Отметим, что данные, следующие за указателем срочности (несрочные данные), нельзя доставить пользователю в тот же буфер с предшествующими срочными данными, если только граница для пользователя четко не обозначена.
Чтобы различить несколько ожидающих RECEIVE и компенсировать буфер, который не полностью заполнен, код возврата сопровождается указателем буфера и счетчиком байтов, указывающим реальную длину полученных данных.
Альтернативные реализации RECEIVE могут иметь TCP, который выделяет буферную память, или TCP может совместно с пользователем использовать кольцевой буфер.
Close (Закрыть)
Эта команда вызывает закрытие указанного соединения. Если соединение не открыто, или же вызывающий процесс не уполномочен использовать это соединение, возвращается ошибка. Закрытие соединения предназначено для элегантной работы в том смысле, что ожидающие SEND будут переданы (и переданы повторно), когда позволит управление потоком, пока все не будет обслужено. Таким образом, допустимо выполнить несколько вызовов SEND, за которыми следует CLOSE, и ожидать, что все данные будут посланы в место назначения. Также должно быть ясно, что пользователи могли бы продолжать RECEIVE (получать) на закрытых соединениях, так как другая сторона могла бы пытаться передавать свои завершающие данные. Фактически CLOSE означает: "У меня для передачи больше ничего нет", а не "Я больше ничего не буду принимать". Может случиться (если протокол на уровне пользователя не очень хорошо проработан), что сторона не сможет избавиться от всех своих данных до того, как закончится выделенное время. В этом случае CLOSE превратится в ABORT, и закрывающий TCP прервется. Пользователь может закрыть соединение в любое время по своей собственной инициативе или в ответ на различные предложения от TCP (например, выполнено удаленное закрытие, превышена задержка передачи, место назначения недоступно).
Так как закрытие соединения требует коммуникации с внешним TCP, соединение может оставаться в закрытом состоянии в течение некоторого времени. Попытки повторно открыть соединение, прежде чем TCP ответит на команду CLOSE, будет приводить к сообщению об ошибке. CLOSE также подразумевает вызов функции push (выталкивания данных).
Status Abort (Прервать)
Эта команда вызывает прерывание всех ожидающих SEND и RECEIVE, удаление ТСВ и отправку специального сообщения RESET для TCP на другой стороне соединения. В зависимости от реализации пользователи могут получать указания о прерывании для каждой ожидающей команды SEND или RECEIVE или просто получить подтверждение команды ABORT.
Протокол IP создан для использования в связанных системах компьютерных коммуникационных сетей с коммутацией пакетов. Протокол IP обрабатывает передаваемые от источника к месту назначения блоки данных, называемые дейтаграммами, где источниками и местами назначения являются хосты, идентифицированные адресами фиксированной длины. Протокол IP предусматривает также фрагментацию и повторную сборку длинных дейтаграмм.
Функции IP ограничены доставкой пакетов битов (дейтаграмм Интернета) от источника к месту назначения через связанную систему сетей. В нем не существует механизмов для обеспечения надежности двухточечной передачи данных, управления потоком, упорядочивания или других служб, присутствующих обычно в протоколах взаимодействия хостов. Протокол IP может использовать службы поддерживающих его сетей для предоставления служб различных типов и качества.
Этот протокол вызывается протоколами взаимодействия хостов в среде Интернета. Он вызывает протоколы локальных сетей для переноса дейтаграмм Интернета к следующему шлюзу или хосту места назначения. Например, модуль ТСР будет вызывать модуль IP, чтобы получить сегмент ТСР (включая заголовок ТСР и данные пользователя) как часть с данными дейтаграммы IP. Модуль ТСР будет предоставлять адреса и другие параметры в заголовке IP модулю IP как аргументы вызова. Модуль IP будет затем создавать дейтаграмму IP и вызывать интерфейс локальной сети для передачи дейтаграммы.
Протокол IP реализует две базовые функции: адресацию и фрагментацию. Модули IP используют адреса, передаваемые в заголовке ГР, для передачи дейтаграмм IP в направлении их места назначения. Выбор пути доступа для передачи называется маршрутизацией. Модули IP используют поля заголовка IP в случае необходимости для фрагментации и повторной сборки дейтаграмм IP.
Модель работы состоит в том, что модуль IP располагается на каждом хосте, вовлеченном в коммуникацию Интернета, и на каждом шлюзе, который соединяет сети. Эти модули используют общие правила для интерпретации полей адреса и для фрагментации и сборки дейтаграмм IP. Кроме того, эти модули (особенно на шлюзах) имеют процедуры для принятия решений о маршрутизации и другие функции.
Протокол IP интерпретирует каждую дейтаграмму IP как независимую сущность, не связанную с другой дейтаграммой IP. Не существует никаких соединений или логических связей (виртуальных или каких-либо других).
Протокол IP использует четыре ключевых механизма при предоставлении своих служб: тип службы, время жизни, параметры и контрольная сумма заголовка. Тип службы используется для указания качества желательной службы. Тип службы является абстрактным или обобщенным множеством параметров, характеризующих варианты служб, предоставляемых в сетях, из которых состоит Интернет. Это указание типа службы должно использоваться шлюзами для выбора параметров реальной передачи для определенной сети, которая будет применяться для следующего перехода или для следующего шлюза при маршрутизации дейтаграммы IP. Время жизни является указанием верхней границы времени жизни дейтаграммы IP. Оно задается отправителем дейтаграммы и уменьшается в точках вдоль маршрута, где оно обрабатывается. Если время жизни достигает нуля до того, как дейтаграмма Интернета достигает своего места назначения, дейтаграмма IP разрушается. Время жизни можно считать пределом времени саморазрушения.
Параметры, предоставляемые для управляющих функций, необходимы или полезны в некоторых ситуациях, но для большинства обычных коммуникаций не нужны. Параметры включают обеспечение отметок времени, безопасности и специальной маршрутизации. Контрольная сумма заголовка предоставляет проверку того, что информация, используемая при обработке дейтаграмм IP, была передана правильно. Данные могут содержать ошибки. Если контрольная сумма заголовка неправильная, дейтаграмма IP тотчас отбрасывается сущностью, которая обнаружила ошибку. Протокол IP не предоставляет надежного средства коммуникации. Не существует подтверждений между конечными точками или точками перехода. Отсутствует контроль ошибок данных, только контрольная сумма заголовка. Не существует повтора передачи и управления потоком. Обнаруженные ошибки могут сообщаться через протокол IСМР, который реализован в модуле протокола IP.
Протокол IP, с одной стороны, общается с протоколами коммуникации хостов более высокого уровня, а с другой стороны, с протоколом локальной сети.
Протокол блоков сообщений сервера (SMB — Server Message Blocks) является рабочей лошадкой мира Windows NT и Windows 2000. Он используется между компьютерами для общего доступа к файлам, принтерам, последовательным портам и для коммуникационных абстракций, таких как именованные каналы и почтовые ящики. SMB является клиент-серверным протоколом типа запрос-ответ.
Протокол SMB превратился в общую файловую систему Интернета (Common Internet File System, CIFS). CIFS предоставляет межплатформенный механизм клиентских систем для запроса служб файлов и печати на серверных системах. Он поддерживает файлы и печать, используя команды доступа open (открыть), close (закрыть), read (читать), write (писать) и seek (искать). Кроме того, он поддерживает доступ к файлам и записям как в блокированном, так и в неблокированном режиме. Когда приложение блокирует файл, ему не могут помешать другие приложения. Блокированные файл или запись недоступны не блокирующим приложениям.
SMB предоставляет кэширование с опережающим чтением и с обратной записью. Это безопасные операции до тех пор, пока только один клиент имеет доступ к файлу. Кэширование чтения и оптимизация упреждающего чтения являются безопасными при доступе к файлу или в режиме только чтения. Если несколько клиентов пытаются одновременно записывать в файл, то ничто не будет безопасным; поэтому все файловые операции должны управляться на сервере. SMB уведомляет обращающегося к файлу клиента об изменениях в режиме доступа, чтобы клиент мог использовать оптимальный метод доступа.
Приложения регистрируются для уведомления сервером об изменениях содержимого файла или каталога. Это позволяет приложению знать, когда обновить изображение, не требуя от него постоянно запрашивать сервер.
Существует почти столько же различных версий протокола SMB, сколько и поставщиков программного обеспечения. Каждая версия предоставляет дополнительные функции, свойства и средства. Чтобы справиться с этим изобилием, SMB выполняет так называемое согласование диалектов. Когда два компьютера вступают в контакт, они согласовывают диалект или версию SMB, которая будет использоваться при их общении. Это критический шаг в терминах как производительности, так и безошибочной коммуникации, так как каждый диалект может предоставлять различные сообщения, а также изменения в полях и семантике существующих сообщений других диалектов. В дополнение к обычным атрибутам файлов, например, времени создания и модификации, такими приложениями, как Word могут добавляться другие элементы, чтобы включить, например, имя автора или описание содержимого.
Протокол может поддерживать виртуальные тома, используя файловую систему, которая может охватывать несколько томов и серверов, но выглядеть при этом для клиентской машины как находящаяся на одном сервере. Файлы и каталоги поддерева могут перемещаться на другие серверы, имена при этом изменять не придется. В этом случае не нужно будет делать изменения на настольном компьютере, когда делаются изменения на сервере. Эти поддеревья могут также реплицироваться для выравнивания нагрузки и устойчивости к ошибкам. Когда клиент запрашивает файл, SMB использует направления для пересылки клиента на сервер, который содержит данные. Все это происходит за сценой без вмешательства клиента.
SMB позволяет клиенту преобразовывать имена серверов с помощью DNS, WINS, LMHOSTS или любого другого механизма преобразования имен. Это перемещает нас из неструктурированного, "плоского" пространства серверных имен в иерархически организованное пространство, поддерживающее более широкий диапазон взаимодействия. Чтобы сберечь полосу пропускания, SMB может пакетировать запросы в одном сообщении для минимизации задержки перемещения туда и обратно, даже когда более поздние запросы зависят от результатов предыдущих; он поддерживает также имена файлов в кодировке Unicode.
Обзор работы SM В
Для получения доступа к файлу на сервере клиентское приложение должно разобрать полное имя файла, чтобы определить имя сервера и относительное имя на этом сервере, разрешить имя сервера в адрес транспортировки, создать соединение с сервером и затем обменяться сообщениями. Если имя сервера было ранее разрешено, то оно может находиться в кэше, поэтому разрешение имени может не понадобиться. Кроме того, если предыдущее соединение все еще доступно, то новое соединение тогда не потребуется. Этот процесс повторяется множество раз в течение нормального рабочего дня. Если соединение простаивало в течение некоторого времени, оно будет разорвано.
Сетевая производительность увеличивается, если клиент может локально буферизовать данные файла. Это связано с тем, что клиент не должен записывать информацию в файл на сервере, если знает, что никакой другой процесс не получает доступа к данным. Таким же образом клиент может буферизовать данные опережающего считывания из файла, если знает, что никакой другой процесс не записывает данные.
Оппортунистические блокировки, или oplocks, позволяют клиентам динамически изменять их стратегию буферизации согласованным образом. Все версии SMB из LAN-MAN 1.0 способствуют поддержке oplocks.
Три различных вида оппортунистических блокировок перечислены ниже.
1. Исключающая oplock позволяет клиенту открыть файл для своего собственного персонального использования, чтобы выполнить произвольную буферизацию.
2. Пакетная oplock позволяет клиенту держать на сервере открытый файл, даже если локальное средство доступа (accessor) на клиентской м шине закрыло файл.
3. Level II oplock позволяет нескольким машинам читать файл, если среди них нет записывающих клиентов. Level II oplock поддерживаются в том случае, если согласованный диалект будет LM 0.12 или больше.
Открыв файл, клиент запрашивает сервер задать на файле определенную oplock. Ответ сервера указывает тип oplock, предоставленный клиенту, позволяя ему соответствующим образом настроить свою политику буферизации.
SMB_COM_LOCKING_ANDX SMB используется для передачи информации ответа и прерывания oplock. Рассмотрим каждый из этих механизмов блокирования более подробно.
