Облегченный протокол ввода/вывода

Облегченный протокол ввода/вывода

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Изобретение в целом относится к системам и способам удаленного доступа к файлам, более конкретно к методам разгрузки обработки ввода/вывода с использованием Удаленного Прямого Доступа к Памяти (RDMA).

Уровень техники

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

Одним подходом к разрешению этой проблемы является разгрузка чрезмерного ввода/вывода (I/O) и сетевой обработки из CPU. В сетевой среде использование распределенных файловых систем и транспортных протоколов, подобных NFS или SMB/CIFS, позволяет отправлять запросы I/O от локальной машины к удаленной машине. Однако это не является необходимым в случае, когда локальная машина будет достигать значительной экономии в обработке с помощью таких подходов.

В контексте единственной машины нагрузка обработки I/O может быть облегчена разгрузкой задач I/O для контроллера прямого доступа к памяти (DMA). Технология Удаленного Прямого Доступа к Памяти (RDMA) является более недавно развивающимся расширением DMA для множества сетевых компьютеров. RDMA позволяет перемещать данные между буферами памяти на двух находящихся в связи машинах, оборудованных RDMA-адаптированными сетевыми интерфейсными платами (NICs), не требующими вовлечения CPU и операционной системы в исходной или целевой машине. RDMA может использоваться для разгрузки I/O обработки в удаленную машину, таким образом приспосабливая локальную машину к восстановлению циклов CPU для приложений. RDMA эксплуатируется в высокоскоростных, высокопропускных межсоединительных технологиях, таких как Виртуальная Интерфейсная Архитектура (VIA), InfiniBand и iWarp. Эти межсоединения разрабатываются, в частности, для высоконадежных сетевых соединений между кластерами серверных узлов в центре обработки данных или другой локальной среде с совместным использованием файлов.

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

Сущность изобретения

В соответствии с одним аспектом настоящего изобретения обеспечивается система для разгрузки задания ввода/вывода (I/O) из первого компьютера во второй компьютер. Система включает в себя клиента, работающего на первом компьютере, и сервер, работающий на втором компьютере. Система дополнительно включает в себя один или более RDMA каналов, связывающих первый компьютер и второй компьютер. Клиент и сервер связываются в соответствии с протоколом ОПВВ, содержащим этап обнаружения сети и этап обработки I/O. Протокол ОПВВ используется в связи с другим сетевым протоколом, таким как SMB/CIFS, обеспечивающим инфраструктуру защиты и аутентификации второго протокола. Для обеспечения лучшей модели защиты модель I/O в протоколе является асимметричной: считывание выполняется с помощью RDMA, тогда как запись выполняется с помощью операций отправки.

В соответствии с другим аспектом настоящего изобретения обеспечивается способ для разгрузки задания I/O из первого компьютера во второй компьютер. Способ имеет преимущество общих приспособленных для RDMA устройств связи на двух компьютерах и является связанным с облегченным клиентско-серверным протоколом ввода/вывода ОПВВ (LWIO). Протокол в целом содержит этап обнаружения, за которым следует этап обработки I/O. В течение этапа обнаружения клиент и сервер определяют минимальный список совместно используемых RDMA провайдеров. В течение этапа обработки I/O клиент посылает запросы I/O для разгрузки во вторую машину.

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

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

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

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

Краткое описание чертежей

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

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

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

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

Фиг. 4А является схемой, в целом иллюстрирующей представление примерного клиентского сообщения запроса согласования в соответствии с вариантом осуществления изобретения.

Фиг. 4В является схемой, в целом иллюстрирующей представление примерного ответа согласования сервера в соответствии с вариантом осуществления изобретения.

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

Фиг. 6А является схемой, в целом иллюстрирующей представление примерного клиентского сообщения запроса аутентификации в соответствии с вариантом осуществления изобретения.

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

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

Фиг. 7А является схемой, в целом иллюстрирующей представление примерного клиентского сообщения файла регистрации в соответствии с вариантом осуществления изобретения.

Фиг. 7В является схемой, в целом иллюстрирующей представление примерного серверного ответа о статусе, завершающего файловую регистрацию, в соответствии с вариантом осуществления изобретения.

Фиг. 8 является схемой, в целом иллюстрирующей шаги, используемые в отношении завершения выполнения запроса I/O в режиме опроса и в режиме отсутствия опроса, в соответствии с вариантом осуществления изобретения.

Фиг. 9А является схемой, в целом иллюстрирующей представление примерного клиентского сообщения запроса прерывания в соответствии с вариантом осуществления изобретения.

Фиг. 9В является схемой, в целом иллюстрирующей представление примерного серверного ответа о статусе, завершающего запрос прерывания, в соответствии с вариантом осуществления изобретения.

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

Фиг. 11А является схемой, в целом иллюстрирующей представление примерного серверного дельта доверительного сообщения в соответствии с вариантом сообщения варианта.

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

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

Фиг. 12А является схемой, в целом иллюстрирующей представление примерного клиентского сообщения запроса закрытия в соответствии с вариантом осуществления изобретения.

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

Фиг. 13А является схемой, в целом иллюстрирующей представление примерного клиентского сообщения запроса отмены в соответствии с вариантом осуществления изобретения.

Фиг. 13В является схемой, в целом иллюстрирующей представление примерного серверного ответа о статусе, завершающего запрос отмены, в соответствии с вариантом осуществления изобретения.

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

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

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

Фиг. 14D является схемой, в целом иллюстрирующей представление примерного серверного блока статуса I/O, завершающего запрос считывания в случае режима опроса, в соответствии с вариантом осуществления изобретения.

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

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

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

Фиг. 15D является схемой, в целом иллюстрирующей представление примерного серверного блока статуса I/O, завершающего запрос записи в случае режима опроса, в соответствии с вариантом осуществления изобретения.

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

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

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

Фиг. 16D является схемой, в целом иллюстрирующей представление примерного серверного блока статуса I/O, завершающего запрос завершения запроса векторного считывания в случае режима опроса, в соответствии с вариантом осуществления изобретения.

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

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

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

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

Фиг. 17Е является схемой, в целом иллюстрирующей представление примерного серверного блока статуса I/O, завершающего запрос векторной записи в случае режима опроса, в соответствии с вариантом осуществления изобретения.

Подробное описание

Некоторые варианты осуществления настоящего изобретения описаны ниже со ссылкой на фиг. 1-17Е. Однако специалисты в этой области техники без труда оценят, что детальное описание, приведенное здесь с учетом этих чертежей, дано с целью иллюстрации, и изобретение простирается за эти варианты осуществления.

Фиг. 1 является схемой, в целом иллюстрирующей некоторые особенности типичной сетевой клиентско/серверной среды, в которой могут быть реализованы аспекты настоящего изобретения. На фиг. 1 изображены две компьютерные машины, помеченные как Host A 101 и Host B 121. Хотя изобретение может быть применено в среде, включающей в себя компьютеры множества различных типов и применений, в одном типичном сценарии Host A 101 функционирует как серверная машина прикладных программ, загруженная интенсивной работой I/O, такой как сервер базы данных.

Каждый Host A 101 и Host B 121 включает в себя несколько интерфейсных сетевых плат (ИСП) (NICs) 109, 111, 113, 133, 135, 137, разрешающих сетевую передачу данных с одной машины на другую. Среди этих ИСП есть ИСП 109, 111, 135, 137, разрешающие RDMA передачу данных. Как показано, не-RDMA сетевая линия связи 119 и RDMA канал 117 присутствуют между двумя хост-компьютерами 101, 121.

ОПВВ клиентская прикладная программа 103, выполняемая на Host A 101, связана с прикладной программой, отвечающей за обработку заданий I/O, которая взаимодействует с услугами 105 считывания/записи I/O режима ядра. ОПВВ клиент 103 используется для разгрузки обработки I/O из Host A 101 в Host B 121. На Host B 121 выполняется ОПВВ сервер 123. В соответствии с ОПВВ протоколом, описанным здесь, ОПВВ клиент 103 связывается с ОПВВ сервером 123. ОПВВ клиент 103 и ОПВВ сервер 123 используют установленные буферы 107, 127, разрешающие прямую передачу данных, связанных с файлом, посредством RDMA канального соединения 117. Задания на считывание и запись посредством сообщений ОПВВ протокола разгружаются в Host B 121. Сервер 123 пропускает запросы I/O к файловой системе 129, которая служит в качестве интерфейса к жесткому диску 131.

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

В варианте осуществления изобретения, описанном ниже, ОПВВ протокол используется в связи с другим сетевым протоколом, таким как SMB или CIFS, для использования преимущества существующей инфраструктуры защиты и аутентификации другого протокола. Это помогает минимизировать верхний слой ОПВВ протокола. Как проиллюстрировано на фиг. 1, ОПВВ сервер 123 на Host B 121 работает над SMB сервером 125. SMB клиент (не показан) также выполняется на Host А 101 и взаимодействует с ОПВВ клиентской прикладной программой 103.

ОПВВ протокол содержит два этапа: этап обнаружения, за которым следует этап I/O. В структурах данных, связанных с вариантом осуществления изобретения, описанном здесь, размеры данных являются следующими:

Фиг. 2 иллюстрирует этапы, используемые на этапе обнаружения ОПВВ протокола в варианте осуществления изобретения. В отношении узла, на котором осуществляется ОПВВ сервер, на этапе 201 ОПВВ сервер регистрируется SMB/CIFS сервером, работающим на этой главной машине. В соответствии с этой регистрацией, на этапе 203 SMB/CIFS сервер уведомляет SMB/CIFS клиента, работающего на удаленном узле, что ОПВВ сервер доступен. На этапе 205 ОПВВ клиент запрашивает ключ возобновления серверного запроса. Ключ возобновления является механизмом аутентификации, который описан в другой заявке того же заявителя, что и настоящий заявитель, «Способ и система для доступа к файлу (Ключ возобновления)», заявка на патент США № ________, дата подачи 24 октября 2003, которая настоящим включена сюда посредством ссылки.

На этапе 207 ОПВВ сервер пропускает ключ возобновления серверного запроса обратно к клиенту. В варианте осуществления изобретения ключ возобновления серверного запроса имеет следующую структуру:

Фиг. 3 дает иллюстративное представление ключа 219 возобновления серверного запроса. Ключ 221 возобновления (ResumeKey), Метка 223 времени (Timestamp) и Pid 225 (полезные данные) формируются на сервере и являются невидимыми для клиента. Содержание (Context) 229 является матрицей, содержащей UNC имя, которое используется ОПВВ клиентом для контакта с сервером. ContextLenght 227 является числом байтов в Context 229.

Сетевое обнаружение

Когда клиентская прикладная программа принимает ключ 219 возобновления серверного запроса, она извлекает имя UNC сервера из поля Контекста 229. Возвращаясь к фиг. 2, на этапе 209 клиент открывает канал к ОПВВ серверу. Канал используется для автоматического обнаружения приспособленных для RDMA устройств, которые являются доступными в сети, описанным ниже способом. Это является важной и полезной особенностью настоящего изобретения; механизмы адресного разрешения, подобные ARP, в целом отсутствуют в VIA сетях и подобных сетях.

Клиент затем запрашивает у сервера список его приспособленных для RDMA устройств («провайдеров»), которые доступны для использования с ОПВВ протоколом. Запрашивание выполняется путем запроса согласования, который клиент формирует и отправляет на сервер через новый открытый канал на этапе 211. В варианте осуществления изобретения запрос согласования имеет следующую структуру:

Фиг. 4 дает иллюстративное представление пакета 231 запроса согласования в варианте осуществления изобретения. Запрос согласования включает в себя управляющий заголовок 223, поле 235 клиентского имени в Уникоде фиксируемой длины, клиентский UUID 237, используемый в качестве ключа, размер 239 локального буфера для получения ответа и список 241 провайдеров. В управляющем заголовке 233 хранится ProtocolId 'LWIO' 243 в качестве первых четырех байтов заголовка.

RevID 245 имеет текущее заданное значение 0х1001, LWIO_REV_ID. Opcode (Код операции) 247 имеет текущее заданное значение 0xfe, LWIO_CONTROL_OPCODE_NEGOTIATE. Length (Длина) 249 является размером в байтах пакета завершения для отправки сервером, включающего все данные, определенные кодом операции.

Имя 235 клиента (ClientName) используется сервером для идентификации клиента. Ключ (Key) 237 используется в последующей процедуре аутентификации, заданной сетью, как описано ниже. Длина ответа (ResponseLenght) 239 является размером буфера для приема согласованного ответа от сервера, как описано ниже. Число 251 провайдеров (ProviderCount) является числом провайдеров, связанных с клиентской машиной, и о которых клиент информирует сервер. Список 241 провайдеров (Provider list) содержит число ProviderCount провайдеров.

В элементе списка 241 провайдера Имя (Name) 253 является именем провайдера. Для того, чтобы обнаружить совместимые сети, клиенту и серверу предпочтительно следует использовать одинаковое имя для одного и того же провайдера. InstanceCount 255 является числом устройств провайдера конкретного типа. Таблица 257 образцов (Instance table) является таблицей пар сеть/дискриминатор, в которой пара служит для описания специфичным для устройства образом, как сформировать удаленное соединение. HostAddressLen 259 является длиной адреса 263 специфичного для сети узла. DescriminatorLen 261 является длиной специфичного для сети дискриминатора 265. Следующими за этими полями длин являются байты HostAddressLen адреса 263 узла и байты DiscriminatorLen дискриминатора 265.

Возвращаясь к фиг. 2, приняв запрос согласования с клиентским списком провайдеров, на этапе 213 сервер определяет, какие приспособленные для RDMA устройства связи являются общими с клиентом. На этапе 215 сервер отправляет согласованный ответ клиенту по каналу, включая список совместно используемых провайдеров. В варианте осуществления изобретения согласованный ответ имеет следующую структуру:

.

Фиг. 4 дает иллюстративное представление ответа 267 согласования в варианте осуществления изобретения. Управляющий заголовок 269 является запросом согласования за исключением того, что Length 271 теперь отражает размер ответного сообщения 267. SrvName 273 содержит имя сервера. Ключ (Key) 275 является генерируемым сервером GUID для использования клиентом. Как будет объяснено ниже, клиент отправляет Key обратно на сервер в запросе аутентификации по новому соединению, используя одно из общих устройств связи. ProviderCount 277 является числом провайдеров в списке 279 провайдеров. Список 279 провайдеров содержит список провайдеров, общих для сервера и клиента. Здесь нет гарантии того, что клиент может действительно соединяться с этими провайдерами.

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

Следующие заданные флаги используются в качестве модификаторов в соединении клиент-к-серверу:

Соответствующие сообщения клиент-к-серверу в ОПВВ протоколе отображает структуру общего заголовка. Общий заголовок имеет следующий формат в варианте осуществления изобретения:

.

Аутентификация соединения

Фиг. 5 иллюстрирует этапы, используемые клиентом и сервером в варианте осуществления изобретения, в течение остатка начального этапа ОПВВ протокола. На этапе 601 клиент устанавливает соединение с сервером через совместно используемое средство связи, как объяснено выше. Клиент и сервер теперь взаимно аутентифицируют новое соединение. На этапе 603 клиент отправляет сообщение запроса аутентификации (LWIO_OPCODE_AUTH) на сервер. Аутентификация делается для предотвращения получения доступа путем обмана со стороны сервера и со стороны клиента. Если аутентификация завершается не своевременно, то соединение прекращается.

Фиг. 6А дает иллюстративное представление клиентского сообщения запроса аутентификации в варианте осуществления изобретения. Сообщение 617 аутентификации содержит общий заголовок 619, за которым следует структура 621 LWIO_AUTH_PARAMS. В заголовке 619 Length 623 устанавливается равным числу байтов, отправленных на сервер (размер общего заголовка 619 плюс размер LWIO_AUTH_PARAMS 621). Opcode 625 устанавливается в LWIO_OPCODE_AUTH (0х6). Флаги (Flags) 627 устанавливаются в LWIO_HDR_FLAG_INTERRUPT. Опознавательная запись (Cookie) 629 в этих и других клиентских сообщениях протокола устанавливается равным значению, выбранному клиентом и в ответ отправленное обратно на сервер. Значение Cookie обычно используется для согласования запроса с ответом сервера. DataVa 631 устанавливается равным адресу, по которому серверу следует RDMA серверные параметры аутентификации. DataMh 633 имеет RDMA ассоциативную управляемую память с DataVa 631.

В варианте осуществления изобретения LWIO_AUTH_PARAMS структура имеет следующий формат:

.

В сообщении 617 аутентификации LWIO_AUTH_PARAMS 621 формирует вторую часть пакета. Magic 635 устанавливается равным 'LWIO'. RevID 637 устанавливается равным LWIO_REV_ID. Endian 639 устанавливается равным размеру (ULONG_PTR). PageSize 641 устанавливается на размер страницы CPU (4 кбайт на 32-битных машинах и 8 кбайт на 64-битных машинах). BaseSequence 643 устанавливается на 0. MaxRdmaWindowSize 645 предназначается для установки равным максимальному числу байтов, которые клиент может принять при RDMA передаче; в отображенном варианте осуществления оно устанавливается на 64 кбайт. MaxSendBufferSize 647 предназначается для установления равным числу байт, которые клиент может отправить серверу в одном запросе; в отображенном варианте осуществления оно устанавливается равным 1 кбайт. MaxRecvBufferSize 649 предназначается для установки равным числу байтов, которые клиент установил для приема данных с сервера; в отображенном варианте оно устанавливается равным 16 байтам. HeaderSize 651 устанавливается на число байт в заголовке 619 ОПВВ протокола. Доверия (Credits) 652 устанавливаются на начальное число буферных доверий, которые клиент желает иметь. Использование доверий объясняется ниже. Сервер может удовлетворять или может не удовлетворять запрос клиента. RdmaReadSupported 653 устанавливается на 0, если клиент не поддерживает операции считывания RDMA, и устанавливается на 1, если клиент поддерживает считывание RDMA.

Часть структуры LWIO_AUTH_PARAMS является набором одной или более опций. Опции используются для создания более гибкой аутентификации. Каждая опция имеет код опции, длину и данные, исключая последнюю опцию в списке LWIO_AUTH_OPTION_END, который имеет только код опции, служащий как нулевая опция, завершающий список опций. В сообщении аутентификации клиент отправляет серверу следующие опции: Ключ (LWIO_AUTH_OPTION_KEY) и подпись (LWIO_AUTH_OPTION_SIGNATURE). Key 655 устанавливается на ключ, ранее возвращенный сервером в ответе согласования. Подпись (Signature) 657 является MD5, подписывающей LWIO_AUTH_PARAMS 621, исключающий подпись.

Возвращаясь к фиг. 5, на этапе 605, если Key, отправленный в сообщении аутентификации, соответствует ключу, который был возвращен в ответе согласования через канал, сервер RDMAs к клиенту в качестве ответа аутентификации структуру LWIO_AUTH_PARAMS, включающую в себя восемь байт SessionId, адрес DataVa и ассоциированный маркер DataMh памяти, обеспечиваемый клиентом в сообщении аутентификации. На этапе 607 сервер отправляет LWIO_MSG_STATUS_RESPONSE для завершения аутентификации.

Фиг. 6В дает иллюстративное представление структуры 659 LWIO_AUTH_PARAMS, возвращенной сервером в варианте осуществления изобретения. Magic 661 устанавливается на 'LWIO'. RevID устанавливается на LWIO_REV_ID. Endian 665 устанавливается на размер (ULONG_PTR). PagSize 667 устанавливается на размер страницы CPU. BaseSequence 669 предназначается для установления клиентом на (BaseSequence+1). MaxRdmaWindowSize 671 предназначается для установления на максимальное число байт, которые клиент может принять в RDMA передаче; в отображаемом варианте осуществления оно устанавливается равным 512 кбайт. MaxSendBufferSize 673 предназначается для установления на число байт, которые сервер отправляет клиенту в одном ответе; в отображаемом варианте осуществления оно устанавливается равным 16 байт. MaxRecvBufferSize 675 предназначается для установки на число байт, которые сервер предварительно установил для приема данных от клиента; в отображаемом варианте осуществления оно устанавливается равным 8 кбайт. HeaderSize 677 устанавливается на число байтов в общем заголовке. Credits 679 устанавливается на начальное число доверий, которые сервер имеет в наличии для клиента. RdmaReadSupported 681 устанавливается на 0, если сервер не поддерживает RDMA считывание, и устанавливается на 1, если сервер поддерживает RDMA считывание. Сервер отправляет следующие параметры: Ключ (Key) (LWIO_AUTH_OPTION_KEY) 683, SessionID (LWIO_AUTH_OPTION_SESSION_ID) 685 и подпись (Signature) (LWIO_AUTH_OPTION_SIGNATURE) 687. Key 683 устанавливается на Ключ, который клиент ранее отправил в Запросе согласования. Значение SessionId 685 используется клиентом при регистрации сервером клиентских файлов, как объяснено ниже. Signature 687 является MD5, подписывающая LWIO_AUTH_PARAMS, исключая Подпись.

В варианте осуществления изобретения структура LWIO_MSG_STATUS_RESPONCE имеет следующий формат:

.

Фиг. 6С дает иллюстративное представление LWIO_MSG_STATUS_RESPONSE 689, возвращенное сервером для завершения аутентификации в варианте осуществления изобретения. Cookie 691 устанавливается на значение cookie, устанавливаемое клиентом в заголовке сообщения аутентификации. Information 693 устанавливается на число байт LWIO_AUTH_PARAMS плюс восемь байт. Статус (Status) 695 устанавливается равным 0х0 (обозначая успех) или 0хС0000022 (обозначая «отказ в доступе»).

Регистрация файлов

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

Фиг. 7А дает иллюстративное представление сообщения файла регистрации, отправленного клиентом на сервер, в варианте осуществления изобретения. Сообщение 701 регистрации содержит общий заголовок 703, за которым следует структура 705 LWIO_FID_PARAMS. Length 707 устанавливается на число байт, отправленных на сервер (размер заголовка 703 плюс размер LWIO_FID_PARAMS 705). Opcode 709 устанавливается на LWIO_OPCODE_REGISTER (0x7). Flags 711 (флаги) устанавливается на LWIO_HDR_FLAG_INTERRUPT. В этом клиентском сообщении и последующем клиентском сообщении Credits 713 устанавливается на число клиентских ожидающих запросов I/O. Поле Credits служит в качестве указания серверу выделить больше доверий соединению, таким образом обеспечивая дополнительные нереализованные запросы I/O, как будет объяснено ниже. Число нереализованных клиентских запросов за один раз не может превышать значение «Credits». Как выше указано, Cookie 715 устанавливается равным значению, специфичному для клиента.

В варианте осуществления изобретения структура LWIO_FID_PARAMS имеет следующий формат:

.

В LWIO_FID_PARAMS 705 сообщения 701 файла регистрации ResumeKey 717 устанавливаются равным ключу возобновления серверного запроса, который был возвращен через канал первоначального доступа к файлу. SessionId 719 устанавливается равным значению SessionId, которое было возвращено сервером во время стадии аутентификации соединения. FlagsAndAttributes 721 устанавливается на Win32 Creat Flags, используемый первоначально для открытия файла.

Возвращаясь к фиг. 5, на этапе 611 сервер отвечает сообщением LWIO_MSG_STATUS_RESPONSE при завершении файловой регистрации. Фиг. 7В дает иллюстративное представление LWIO_MSG_STATUS_RESPONSE 723, отправленного сервером, в варианте осуществления изобретения. Information 725 устанавливается на Fid (Поле ID) (File ID) для использования при отправлении запроса I/O. Status 727 устанавливается равным 0х0 (успех) или другому коду NTSTATUS при неудаче. Cookie 729 устанавливается на значение опознавательной записи, которую клиент установил в заголовке сообщения файла регистрации.

Обработка I/O

В этот момент клиентские соединения установлены и файлы зарегистрированы и начинается этап I/O обработки ОПВВ протокола. Одной ключевой особенностью варианта осуществления ОПВВ протокола является асимметричная модель I/O для считываний и записей. Операции считывания выполняются с помощью RDMA, тогда как записи выполняются с помощью операций отправки. Записи не выполняются с помощью RDMA для обеспечения лучшей модели защиты. Если сервер открывает свою адресную область через ИСП для RDMA, он вносит уязвимость из-за порчи данных, которая может использоваться злонамеренным клиентом. В этом сценарии злонамеренный клиент выдает циклично операции RDMA записи на выданный сервером виртуальный адрес. Так как пространство адресов сервера конечно и в некоторый момент серверные виртуальные адреса должны быть многократно использованы, то злонамеренный клиент в конечном счете захватит сервер с помощью такого же виртуального адреса для другого соединения, заставляя данные записываться в буфер сервера, который может быть связан с другим клиентом. Асимметричная модель I/O в ОПВВ протоколе предохраняет от таких возможностей. Эта особенность является принципиальным отличием между ОПВВ протоколом и другими протоколами передачи файлов на основе RDMA, такими как DAFS.

Возвращаясь к фиг. 5, на этапе 613 клиент начинает установление запросов обработки I/O. Завершения запросов I/O сервер-к-клиенту находятся либо в режиме отсутствия опроса, либо в режиме опроса. В режиме отсутствия опроса завершения I/O основаны на прерываниях с помощью обычных сообщений получения/отправки. В режиме опроса завершения I/O используют RDMA и не основываются на прерываниях.

Блок схема на фиг. 8 в целом иллюстрирует, со стороны ОПВВ сервера, этапы, используемые для варианта осуществления изобретения в отношении завершения запроса I/O в режиме опроса или в режиме отсутствия опроса. Клиентский запрос I/O задает, следует ли серверу отправлять обратно сообщение регистрации-отправки (прерывание CPU) или сообщение RDMA. На этапе 801 сервер определяет, установлен ли флаг LWIO_HDR_FLAG_INTERRUPT в общем заголовке клиентского сообщения запроса I/O. Если флаг установлен, то на этапе 803 сервер завершает выполнение клиентского запроса путем LWIO_MSG_STATUS_RESPONSE с помощью обычной отправки. Если флаг LWIO_HDR_FLAG_INTERRUPT не установлен (режим опроса), тогда сервер завершает выполнение клиентского запроса посредством RDMAing LWIO_IO_STATUS_BLOCK для клиента, как отображено на этапе 805.

Пробуждение клиента в режиме опроса

В режиме опроса клиент может захотеть “заснуть” (войти в спящий режим) в ожидании завершения I/O сервером. Завершения в этом случае отправляются путем RDMA к клиенту, поэтому необходим механизм пробуждения клиента для уведомления о том, что произошло завершение. Если клиент захочет быть разбуженным, он отправляет сообщение на запрос прерывания (LWIO_OPCODE_INTERRUPT) на сервер, принимаемое сервером на этапе 807 Фиг. 8. Сервер, который принимает запрос прерывания, не будет отправлять ответ до