Патент на изобретение №2388039
|
||||||||||||||||||||||||||
(54) ОБЛЕГЧЕННЫЙ ПРОТОКОЛ ВВОДА/ВЫВОДА
(57) Реферат:
Изобретение относится к способам и системам для разгрузки обработки I/O из первого компьютера во второй компьютер с помощью обеспечиваемого посредством RDMA сетевого межсоединения. Техническим результатом является обеспечение облегченного протокола ввода/вывода. Способ и система включают в себя клиент на первом компьютере, обеспечивающийся информацией через RDMA соединение с сервером на втором компьютере посредством облегченного протокола ввода/вывода (ОПВВ). Протокол в целом содержит этап обнаружения сети, за которым следует этап обработки I/O. Во время этапа обнаружения клиент и сервер определяют минимальный перечень совместно используемых способных к RDMA провайдеров. Во время этапа обработки I/O клиент устанавливает запросы I/O для разгрузки второй машины через взаимно аутентифицированный канал. Модель I/O является асимметричной с операциями считывания, воплощаемыми путем обычной отправки. Запросы считывания и записи могут завершаться в режиме опроса и в режиме прерывания. Буферы управляются посредством механизма доверия. 4 н. и 17 з.п. ф-лы, 39 ил.
Область техники, к которой относится изобретение Изобретение в целом относится к системам и способам удаленного доступа к файлам, более конкретно к методам разгрузки обработки ввода/вывода с использованием Удаленного Прямого Доступа к Памяти (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 ОПВВ клиент запрашивает ключ возобновления серверного запроса. Ключ возобновления является механизмом аутентификации, который описан в другой заявке того же заявителя, что и настоящий заявитель, «Способ и система для доступа к файлу (Ключ возобновления)», заявка на патент США На этапе 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. Пробуждение клиента в режиме опроса В режиме опроса клиент может захотеть Фиг. 9А дает иллюстративное представление сообщения запроса на прерывание, отправленного клиентом на сервер, в варианте осуществления изобретения. Сообщение содержит общий заголовок 815. Opcode 817 устанавливается на LWIO_OPCODE_REGISTER (0х9). Flags 819 устанавливается на (LWIO_HDR_FLAG_INTERRUPT| LWIO_HDR_FLAG_CONTROL) (0хС0). Credits 821 устанавливаются на число ожидающих клиентских запросов I/O и Cookie 823 устанавливаются на значение, специфичное для клиента. Сервер отвечает на сообщение запроса прерывания после обработки другого запроса I/O. Фиг. 9 дает иллюстративное представление сообщения 825 LWIO_MSG_STATUS_RESPONSE, отправленного сервером, в варианте осуществления изобретения. Information 827 устанавливается на 0. Status 829 устанавливается на 0х0 (успех) или другой код NTSTATUS при неудаче. Cookie 831 устанавливается равным значению Cookie в заголовке запроса прерывания, отправленного клиентом. Доверия Как было указано, все запросы I/O клиент-к-серверу включают в себя поле доверий в заголовке. Поле доверий является указанием серверу числа нереализованных запросов I/O, которые клиент хотел бы отправить на сервер. Управление довериями является обязанностью сервера. Доверия обеспечивают новое решение проблемы сдвига буферов. Если клиент в настоящее время имеет N доверий, то требуется установить N+1 приемных буферов для отправки сервером клиенту сообщения о доверии. Сервер имеет только один нереализованный запрос доверия во время клиентского соединения в любой момент времени. Сообщения о доверии всегда отправляются в режиме прерывания. Доверительная транзакция содержит инициируемое сервером трехходовое квитирование установления связи между клиентом и сервером. Фиг. 10 иллюстрирует в целом этапы, содержащие доверительную транзакцию в варианте осуществления изобретения. На этапе 1001 сервер отправляет сообщение дельта доверительного запроса во время клиентского соединения. Фиг. 11А дает иллюстративное представление серверного дельта доверительного сообщения в варианте осуществления изобретения. Это сообщение принимает форму LWIO_MSG_STATUS_RESPONSE 1011. Credits соответствуют буферам. Infornation 1013 устанавливается на число доверий, которые клиенту следует отдать (отрицательное число), или число кредитов (лишние буферы), которые сервер заново выделил для использования клиентом (положительное число). Status 1015 устанавливается на LWIO_NOTIFY_CREDIT (0х1). Cookie 1017 устанавливается на 0. Возвращаясь к фиг. 10, клиент принимает сообщение доверия с сервера. Клиенту требуется ответить сообщением LWIO_OPCODE_CREDIT серверу по тому же самому соединению. Это сообщение означает или отказ от единственного доверия или уведомление сервера о числе вновь выделенных доверий, которые клиент использовал. Если Информационное поле (Information field) в серверном сообщении доверия содержит отрицательное число «-N» (этап 1003), то клиент отправляет N LWIO_OPCODE_CREDIT сообщений (одно для каждого доверия, которое требуется предоставить), как указано на этапе 1005. Если Information field положительное, тогда клиент отправляет только одно LWIO_OPCODE_CREDIT сообщение, указанное на этапе 1007. Фиг. 11В дает иллюстративное представление сообщения LWIO_OPCODE_CREDIT, отправленного клиентом, в варианте осуществления изобретения. Сообщение 1019 LWIO_OPCODE_CREDIT содержит общий заголовок 1021. Opcode 1023 устанавливается равным LWIO_OPCODE_CREDIT (0х8). Flags 1025 устанавливается равным LWIO_HDR_FLAG_INTERRUPT (0х80). Credits 1027 устанавливается на число ожидающих клиентских запросов I/O. Cookie 1031 устанавливается равным значению, специфичному для клиента. Если клиент принял положительное дельта доверительное сообщение, то первые 32 бита Сдвига (Offset) 1029 устанавливаются равным числу доверий, выделенных сервером, которые клиент не использовал. Когда клиент возвращает в этом поле, значение большее, чем ноль, сервер обычно не отправляет другого положительного обновленного сообщения до тех пор, пока не отправляется по меньшей мере одно отрицательное обновление. Обычно клиент возвращает ноль. Как отмечено выше, если клиент принял отрицательное (-N) дельта доверительное сообщение, клиент запрашивает послать N доверительных сообщений с сервера, одно для каждого доверия, которое он отдает. Первые 32 бита Offset 1029 в этом случае соответственно устанавливаются в -N, -(N-1), Возвращаясь к фиг. 10, сервер завершает трехходовое квитирование установления связи путем отправки сообщения LWIO_MSG_STATUS_RESPONSE клиенту, указанной на этапе 1009. Фиг. 11С дает иллюстративное представление LWIO_MSG_STATUS_RESPONSE 1033, отправленного сервером, в варианте осуществления изобретения. Information 1037 устанавливается на 0. Если первые 32 бита Offset в заголовке LWIO_OPCODE_CREDIT сообщения, отправленного клиентом, были больше или равны нулю, то Status 1039 устанавливается на 0х0, обозначая успех. Если первые 32 бита Offset были установлены на отрицательное число, сервер устанавливает Status 1039 на LWIO_CREDIT_NOTIFY для разрешения клиенту удалять доверие. Cookie 1035 устанавливается на значение Cookie, установленное клиентом в общем заголовке сообщения LWIO_OPCODE_CREDIT. Закрытие Сообщение закрытия используется для остановки обработки I/O для конкретного Fid, который был заменен во время стадии регистрации. Когда сервер отвечает, любые новые запросы будут давать сбой, пока Fid не повторится циклично. Фиг. 12А дает иллюстративное представление сообщения закрытия, отправленного клиентом, в варианте осуществления изобретения. Сообщение закрытия 1041 содержит общий заголовок 1043. Opcode 1045 устанавливается равным LWIO_OPCODE_CLOSE (0х4). Flags 1047 устанавливается равным LWIO_HDR_FLAG_INTERRUPT (0х80). Credits 1049 устанавливаются на число ожидающих клиентских запросов I/O. Cookie 1053 устанавливается равным значению, специфичному для клиента. Fid 1051 устанавливается на File Id файла, который должен быть закрыт. Сервер отвечает LWIO_MSG_STATUS_RESPONSE. Фиг. 12В дает иллюстративное представление завершения закрытия LWIO_MSG_STATUS_RESPONSE 1055, возвращенное сервером, в варианте осуществления изобретения. Information 1059 устанавливается на 0. Status 1061 устанавливается на 0, указывая на успех. Cookie 1057 устанавливается на значение Cookie, которое было отправлено в клиентском запросе закрытия. Отмена Сообщение отмены используется для остановки обработки I/O для конкретного Fid, который был заменен во время стадии регистрации. Когда выдается отмена, то сервер завершает выполнение запроса. Однако запросы I/O, которые не могут быть отменены, могут еще выполняться на сервере. Фиг. 13А дает иллюстративное представление сообщения отмены, отправленного клиентом, в варианте осуществления изобретения. Сообщение отмены 1063 содержит общий заголовок 1065. Opcode 1067 устанавливается равным LWIO_OPCODE_CANCEL (0х5). Flags 1069 устанавливается равным LWIO_HDR_FLAG_INTERRUPT (0х80). Credits 1071 устанавливается равным числу ожидающих клиентских запросов I/O. Cookie 1075 устанавливается равным значению, специфичному для клиента. Fid устанавливается на File Id, на котором должна выдаваться отмена. Сервер завершает отмену сообщением LWIO_MSG_STATUS_RESPONSE. Фиг. 13В дает иллюстративное представление завершения отмены LWIO_MSG_STATUS_RESPONSE 1077, возвращенное сервером, в варианте осуществления изобретения. Information 1081 устанавливается на 0. Status 1083 устанавливается на 0, указывая на успех. Cookie устанавливается на значение Cookie, которое было установлено в клиентском запросе отмены. Сообщение считывания используется для получения данных с конкретного Fid, который был заменен во время стадии регистрации. Для запроса считывания меньше одного килобайта, если пользовательский буфер не зарегистрирован через ИСП, данные принимаются во внешний заранее зарегистрированный буфер, а копия выполняется в пользовательский буфер, когда данные принимаются с сервера. Это делается потому, что более эффективно копировать малое количество данных, чем регистрировать малые пользовательские буферы. Для больших считываний пользовательский буфер регистрируется и данные прямо принимаются путем RDMA записи. Количество считываемых данных, соответствующих единственному запросу считывания, ограничивается значением MaxRdmaWindowSize сервера. Фиг. 14А и 14С дают иллюстративные представления сообщения считывания, отправленного клиентом, в варианте осуществления изобретения, при этом на Фиг. 14А представляется случай отсутствия опроса, а на Фиг. 14С представляется случай опроса. Сообщение считывания 1401 содержит общий заголовок 1043. Length 1405 устанавливается на число байт для считывания из связанного файла. Opcode 1407 устанавливается на LWIO_OPCODE_READ (0х0). Offset 1417 устанавливается на местоположение байта, в котором начинается считывание файла. Маркер (Marker) 1413 устанавливается на 0xFF. Flags 14099 устанавливается на 0х0 в случае опроса 1427 или на LWIO_HDR_FLAG_INTERRUPT (0х80) в случае отсутствия опроса 1049. Credits 1411 устанавливается на число ожидающих клиентских запросов I/O. Fid устанавливается на File Id, по которому выдается I/O. DataVa 1419 устанавливается на адрес, по которому осуществляют доступ к считываемым данным посредством RDMA, а DataMh 1421 устанавливаются на маркер связанной памяти. В случае отсутствия опроса ImmediateCookie 1423 и Cookie 1425 устанавливаются на значения, специфичные для клиента. Сервер может завершать запрос считывания в этом случае с помощью LWIO_MSG_STATUS_RESPONSE путем обычной отправки или с помощью RDMA с непосредственными данными, если считывание прошло успешно. Непосредственные данные RDMA записи соответственно устанавливаются на значение ImmediateCookie запроса считывания. В случае опроса IosVa 1431 устанавливается на местоположение, по которому статус серверного ответа (LWIO_IO_STATUS_BLOCK) является доступным посредством RDMA, и IosMh устанавливается на маркер связанной памяти. В случае отсутствия опроса, сервер сначала осуществляет доступ посредством RDMA к считываемым данным. Сервер затем может ответить посредством LWIO_MSG_STATUSE_RESPONSE или сервер может отправить непосредственные данные с RDMA считываемыми данными, в этом случае непосредственные данные устанавливаются на значение ImmediateCookie запроса считывания. Фиг. 14В дает иллюстративное представление LWIO_MSG_STATUSE_RESPONSE 1433, возвращенное сервером в случае отсутствия опроса, в варианте осуществления изобретения. Информация 1437 устанавливает на число считанных байт. Status 1439 устанавливается на 0, указывая на успех, или на другой NTSTATUS, указывая на неудачу. Cookie 1435 устанавливается на значение Cookie, установленное клиентом в заголовке сообщения считывания. В случае опроса, сервер сначала осуществляет доступ посредством RDMA к считанным данным. Сервер затем осуществляет доступ посредством RDMA к LWIO_IO_STATUS_BLOCK к клиенту. Фиг. 14D дает иллюстративное представление LWIO_IO_STATUS_BLOCK 1441, возвращенное сервером, в варианте осуществления изобретения. Information 1443 устанавливается на число считанных байт. Status 1445 устанавливается на 0, указывая на успех, или на другой NTSTATUS, указывая на неудачу. Запись Сообщение записи используется для помещения данных в конкретный Fid, который был заменен во время регистрации файла. Все записанные данные посылаются посредством обычных операций отправки. Количество записанных данных ограничивается значением MaxRecvBufferSize сервера. Если клиент отправляет больше данных, чем это, то соединение завершается. Фиг. 15А и 15С дают иллюстративные представления сообщения записи, отправленного клиентом, в варианте осуществления изобретения, при этом на Фиг. 15А представляется случай отсутствия опроса, а на фиг. 15С представляется случай опроса. Сообщение 1501 записи включает в себя общий заголовок 1503. Length 1505 устанавливается на число байт записываемых данных. Opcode 1507 устанавливается на LWIO_OPCODE_WRITE (0х1). Offset 1517 устанавливается на местоположение байта, с которого начинается запись данных файла. Flags 1509, 1529 устанавливаются на 0х0 в случае опроса 1529 или на LWIO_HDR_FLAG_INTERRUPT (0х80) в случае отсутствия опроса 1509. Метка (Marker) 1513 устанавливается на 0xFF. Credits 1511 устанавливается на число ожидающих клиентских запросов I/O. Fid 1515 устанавливается на Fid Id, по которому выдается I/O. Данные для записи 1527 непосредственно следуют за общим заголовком 1503 сообщения записи. В случае отсутствия опроса Cookie 1525 устанавливается на значение, специфичное для клиента. В случае опроса IosVa 1533 устанавливается на местоположение, с которого серверный ответ о статусе (LWIO_IO_STATUS_BLOCK) доступен посредством RDMA, и IosMh 1531 устанавливается на маркер связанной памяти. В случае отсутствия опроса сервер отвечает на сообщение записи посредством LWIO_MSG_STATUS_RESPONSE. Фиг. 15В дает иллюстративное представление LWIO_MSG_STATUS_RESPONSE 1535, возвращенное сервером, в варианте осуществления изобретения. Information 1539 устанавливается на число записанных байт. Statuse 1541 устанавливается на 0, указывая на удачу, или на другой NTSTATUS, указывая на неудачу. Cookie 1531 устанавливается на значение Cookie, установленное клиентом в заголовке сообщения записи. В случае опроса сервер осуществляет доступ посредством RDMA к LWIO_IO_STATUS_BLOCK. Фиг. 15D дает иллюстративное представление LWIO_IO_STATUS_BLOCK 1543, возвращенное сервером, в варианте осуществления изобретения. Information 1545 устанавливается на число записанных байт. Status 1547 устанавливается на 0, указывая на успех, или на другой NTSTATUS, указывая на неудачу. Векторное считывание Векторное считывание используется для получения данных из конкретного Fid, который был заменен во время стадии регистрации, и для распределения данных по страничной основе во множестве сегментов запрашивающего. Все считанные данные отправляются запрашивающему путем RDMA записей с одной RDMA записью из сервера для каждого считанного сегмента. Данные, считанные с диска, являются непрерывными. Число считанных данных ограничивается максимальным числом целевых страниц, которые могут быть описаны в единственном запросе. Это ограничение равно значению MaxRecvBufferSize сервера, деленному на размер (LWIO_RDMA_REGION). Структура LWIO_RDMA_REGION дается ниже. Фиг. 16А и фиг. 16С дают иллюстративные представления сообщения векторного считывания, отправленного клиентом, в варианте осуществления изобретения, при этом фиг. 16А представляет случай отсутствия опроса, а Фиг. 16С представляет случай опроса. Сообщение 1401 считывания содержит общий заголовок 1603, за которым следуют один или более сегментов 1605, 1607 LWIO_RDMA_REGION. В заголовке 1603 Length 1609 устанавливается на число байт данных, считанных из файла. Opcode 1611 устанавливается на LWIO_OPCODE_VEC_READ (0х2). Ofset 1621 устанавливается на местоположение байта, с которого начинается считывание данных файла. Flags 1613, 1631 устанавливаются на 0х0 в случае опроса или на LWIO_HDR_FLAG_INTERRUPT (0х80) в случае отсутствия опроса 1613. Marker 1617 устанавливается на 0xFF. Credits 1615 устанавливается на число ожидающих клиентских запросов I/O. Fid 1619 устанавливается на File Id, по которому выдается I/O. NumPages 1623 устанавливается на число LWIO_RDMA_REGION, которые следуют за общим заголовком 1603. PageSize 1625 устанавливается на размер локальной страницы в байтах. В случае отсутствия опроса ImmediateCookie 1627 и Cookie 1629 устанавливаются равными значениям, специфичным для клиента. Сервер может завершать запрос векторного считывания в этом случае посредством LWIO_MSG_STATUS_RESPONSE путем обычной отправки или посредством RDMA с непосредственными данными, если считывание прошло успешно. Непосредственные данные RDMA записи соответственно устанавливаются на значение ImmediateCookie 1627 запроса считывания. В случае опроса IosVa 1635 устанавливается на местоположение, с которого серверный ответ о статусе (LWIO_IO_STATUS_BLOCK) доступом посредством RDMA, и IosMh 1633 устанавливается на маркер связанной памяти. За общим заголовком непосредственно следует достаточное количество сегментов 1605, 1607 LWIO_RDMA_REGION для охвата длины запроса. Все промежуточные сегменты должны быть в размере одной страницы. Конечный сегмент может быть меньше, чем страница, но он должен быть кратным размеру конечного сектора диска. В варианте осуществления изобретения LWIO_RDMA_REGION имеет следующий формат:
Первый LWIO_RDMA_REGION соответствует первым PageSize считанным байтам, второй LWIO_RDMA_REGION соответствует вторым PageSize считанным байтам и т.д. DataVa 1637 устанавливается на местоположение, отмечающее начало страницы, на которой должны располагаться считанные данные. DataMh 1639 устанавливается на маркер памяти DataVa 1637. Length 1641 устанавливается на PageSize 1625 для всех областей, исключая конечную область, для которой Length может быть меньше, но должна быть кратной размеру конечного сектора диска. В случае отсутствия режима опроса сервер сначала осуществляет доступ посредством RDMA к считываемым данным. Сервер затем может отвечать посредством LWIO_MSG_STATUS_RESPONSE или сервер может отправлять непосредственные данные посредством RDMA считанных данных, в этом случае непосредственные данные устанавливаются на значение ImmediateCookie запроса считывания. Фиг. 16В дает иллюстративное представление LWIO_MSG_STATUS_RESPONSE 1643, возвращенный сервером в случае отсутствия опроса, в варианте осуществления изобретения. Information 1653 устанавливается на число байт считывания. Status 1655 устанавливается на 0, указывая на успех, или на другой NTSTATUS, указывая на неудачу. Cookie устанавливается на значение Cookie, установленное клиентом в заголовке сообщения векторного считывания. В случае опроса сначала сервер обращается посредством RDMA к считанным данным и затем сервер обращается посредством RDMA к LWIO_IO_STATUS_BLOCK. Фиг. 16D дает иллюстративное представление LWIO_IO_STATUS_BLOCK 1651, возвращенное сервером, в варианте осуществления изобретения. Information 1653 устанавливается на число байт считывания. Status 1655 устанавливается на 0, указывая на удачу, или на другой NTSTATUS, указывая на неудачу. Векторная запись Сообщение векторной записи используется для выполнения сбора записей в конкретный Fid, который был заменен во время регистрации файла. Все записанные данные устанавливаются путем обычных операций отправки. Количество записанных данных ограничивается размером MaxRecvBufferSize сервера. Если клиент отправляет больше данных, чем это, соединение заканчивается. Фиг. 17А, 17В и 17С дают иллюстративные представления сообщения векторной записи, отправленного клиентом, в варианте осуществления изобретения, при этом фиг. 17А иллюстрирует случай отсутствия опроса и отсутствия сжатия, фиг. 17В иллюстрирует случай отсутствия опроса и наличия сжатия, а фиг. 17С иллюстрирует случай опроса и сжатия. Сообщение 1701 записи включает в себя общий заголовок 1703, за которым непосредственно следуют записываемые данные 1705. В общем заголовке 1703 Length 1707 устанавливается на число байт записанных данных. Opcode 1709 устанавливается на LWIO_OPCODE_WRITE (0х3). Offset 1719 устанавливается на местоположение байта, с которого начинается запись данных файла. Marker 1715 устанавливается на 0xFF. Credits 1733 устанавливается на число ожидающих клиентских запросов I/O. Fid 1717 устанавливается на File Id, по которому выдается I/O. Флаги 1711, 1721, 1727 устанавливаются равными 0х0, обозначая опрос 1727, или равными другому LWIO_HDR_FLAG_INTERRUPT (0х80) 1711. В последнем случае флаги могут также включать в себя LWIO_HDR_FLAG_COLLAPSE 1721 для указания, что все страницы в записи содержат те же самые данные, так что отправляются только данные одной страницы данных. Это является оптимизацией, направленной на минимизацию передачи избыточных данных. LWIO_HDR_FLAG_COLLAPSE может использоваться, только если флаги зарегистрированного файла включают в себя FILE_NO_INTERMEDIATE_BUFFERING (0х8), и PageSizes, замененные во время стадии аутентификации, являются также кратными друг для друга. В случае сжатого I/O, NumPage 1723 устанавливается на число страниц данных, охваченных I/O. Последняя страница может быть частичной вследствие параметра Length. PageSize 1725 устанавливается на размер локальной страницы в байтах. В случае опроса IosVa 1731 устанавливается на местоположение, с которого серверный ответ о статусе (LWIO_IO_STATUS_BLOCK) доступен посредством RDMA. IosMh 1729 является маркером связанной памяти. В случае отсутствия опроса при отсутствии сжатия и при сжатии I/O сервер отвечает на сообщение записи посредством LWIO_MSG_STATUS_RESPONSE. Фиг. 17D дает иллюстративное представление LWIO_MSG_STATUS_RESPONSE 1733, возвращенного сервером, в варианте осуществления изобретения. Information 1737 устанавливается на число байт записи. Status 1739 устанавливается на 0, указывая на успех, или на другой NTSTATUS, указывая на неуспех. Cookie 1735 устанавливается на значение Cookie, установленное клиентом в заголовке сообщения записи. В случае опроса при отсутствии сжатия и при сжатии I/O сервер RDMAs LWIO_IO_STATUS_BLOCK. Фиг. 17Е дает иллюстративное представление LWIO_IO_STATUS_BLOCK 1741, возвращенного сервером, в варианте осуществления изобретения. Information 1743 устанавливается на число записываемых байт. Status 1745 устанавливается на 0, указывая на успех, или на другой NTSTATUS, указывая на неудачу. Заключение Несмотря на то, что были проиллюстрированы и описаны варианты осуществления изобретения, будет понятно, что различные изменения могут быть сделаны без отрыва от изобретения. Так же любые выполняемые этапы, описанные здесь, могут быть взаимозаменяемыми с другими этапами для достижения такого же результата. К тому же, проиллюстрированные примеры, описанные выше, не предназначены для исчерпания или ограничения изобретения в точных описанных формах. Наоборот, изобретение охватывает все модификации, альтернативы и эквиваленты, попадающие в сущность и объем изобретения.
Формула изобретения
1. Система разгрузки задания ввода/вывода (I/O) из первого компьютера на второй компьютер, содержащая: 2. Система по п.1, в которой упомянутый протокол используется в связи с другим сетевым протоколом. 3. Система по п.2, в которой другой протокол является блоком серверных сообщений (SMB). 4. Система по п.2, в которой другой протокол является общим протоколом доступа к файлам Интернета (CIFS). 5. Считываемый компьютером носитель, хранящий выполняемые компьютером команды, которые при выполнении на компьютере вынуждают компьютер выполнять способ по п.1. 6. Способ разгрузки задания ввода/вывода (I/O) из первого компьютера на второй компьютер, содержащий этапы: 7. Способ по п.6, в котором обнаружение одного или более способных совместно использовать RDMA провайдеров содержит этапы: 8. Способ по п.6, дополнительно содержащий этап: 9. Способ по п.8, в котором регистрация одного или более файлов содержит этапы: 10. Способ по п.6, в котором аутентификация RDMA-соединения дополнительно содержит этапы: 11. Способ по п.10, в котором отправка сервером сообщения запроса аутентификации клиенту выполняется, когда предыдущий ключ является ключом, содержащимся в сообщении согласованного ответа, отправленном сервером клиенту. 12. Способ по п.10, дополнительно содержащий этап: 13. Способ по п.6, в котором посылка запроса обработки I/O содержит отправление клиентом одного из: (а) запроса закрытия, (b) запроса отмены, (с) запроса считывания, (d) запроса записи, (е) запроса векторного считывания и (f) запроса векторной записи. 14. Способ по п.13, дополнительно содержащий этапы: 15. Способ по п.13, в котором посылка запроса обработки I/O содержит отправление клиентом запроса векторной записи, который включает в себя флаг сжатия в заголовке запроса. 16. Способ по п.15, в котором посылка запроса обработки I/O дополнительно включает в себя указание, должно ли завершение сервером быть в режиме опроса. 17. Способ по п.16, в котором указание, должно ли завершение сервером быть в режиме опроса, содержит указание того, что завершение сервером не должно быть в режиме опроса, посредством установления флага прерывания в заголовке запроса обработки I/O. 18. Способ по п.16, дополнительно содержащий этап: 19. Способ по п.16, дополнительно содержащий этап: 20. Способ по п.6, в котором посылка запроса обработки I/O дополнительно включает в себя заданное число разрешений на передачу в заголовке запроса. 21. Считываемый компьютером носитель, хранящий выполняемые компьютером команды, которые при выполнении на компьютере вынуждают компьютер выполнять способ по п.6.
РИСУНКИ
|
||||||||||||||||||||||||||
595
заснуть
(войти в спящий режим) в ожидании завершения I/O сервером. Завершения в этом случае отправляются путем RDMA к клиенту, поэтому необходим механизм пробуждения клиента для уведомления о том, что произошло завершение. Если клиент захочет быть разбуженным, он отправляет сообщение на запрос прерывания (LWIO_OPCODE_INTERRUPT) на сервер, принимаемое сервером на этапе 807 Фиг. 8. Сервер, который принимает запрос прерывания, не будет отправлять ответ до тех пор, пока запрос I/O не завершается сервером (этап 809). Завершение отправляется клиенту на этапе 811 путем обычной отправки, прерывающей клиента. Только одно сообщение прерывания может быть выдано для данного клиентского соединения.
, -1. Когда сервер принимает клиентское доверительное сообщение с первыми 32 битами Offset 1029, установленными на -1, сервер предполагает, что клиент завершил обработку серверного доверительного сообщения и может принимать новые доверительные сообщения.
