Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 7)

Метод GET служит для получения любой информации, идентифицированной URI-Запроса. Если URI- Запроса ссылается на процесс, выдающий данные, в качестве ответа будут выступать данные, сгенерированные данным процессом, а не код самого процесса (если только это не является выходными данными процесса).

Метод GET изменяется на «условный GET», если сообщение запроса включает в себя поле заголовка «If-Modified-Since». В ответ на условный GET, тело запрашиваемого ресурса передается только, если он изменялся после даты, указанной в заголовке «If-Modified-Since». Алгоритм определения этого включает в себя следующие случаи:

• если код статуса ответа на запрос будет отличаться от «200 OK», или дата, указанная в поле заголовка «If-Modified-Since» некорректна, ответ будет идентичен ответу на обычный запрос GET;

• если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET;

• если ресурс не изменялся после указанной даты, сервер вернет код статуса «304 Not Modified».

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

Метод HEAD аналогичен методу GET, за исключением того, что в ответе сервер не возвращает «Тело-Ответа». Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса. Метод "Условный HEAD", аналогичный условному GET, не определен.

Метод POST используется для запроса сервера, чтобы тот принял информацию, включенную в запрос, как субординантную для ресурса, указанного в Строке Статус в поле URI-Запроса. Метод POST был разработан, чтобы была возможность использовать один общий метод для следующих функций:

• аннотация существующих ресурсов;

• добавление сообщений в группы новостей, почтовые списки или подобные группы статей;

• доставка блоков данных процессам, обрабатывающим данные;

• расширение баз данных через операцию добавления.

Реальная функция, выполняемая методом POST, определяется сервером и обычно зависит от URI- Запроса. Добавляемая информация рассматривается как субординатная указанному URI в том же смысле, как файл субординатен каталогу, в котором он находится, новая статья субординатна группе новостей, в которую она добавляется, запись субординатна базе данных.

Клиент может предложить URI для идентификации нового ресурса, включив в запрос заголовок "URI". Тем не менее, сервер должен рассматривать этот URI только как совет и может сохранить тело запроса под другим URI или вообще без него.

Если в результате обработки запроса POST был создан новый ресурс, ответ должен иметь код статуса, равный "201 Created", и содержать URI нового ресурса.

Метод PUT запрашивает сервер о сохранении «Тело-Запроса» под URI, равным URI-Запроса. Если URI-Запроса ссылается на уже существующий ресурс, «Тело-Запроса» должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URI-Запроса не существует, и данный URI может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URI. Если был создан новый ресурс, сервер должен информировать направившего запрос клиента через ответ с кодом статуса «201 Created». Если существующий ресурс был модифицирован, должен быть послан ответ «200 OK», для информирования клиента об успешном завершении операции. Если ресурс с указанным URI не может быть создан или модифицирован, должно быть послано соответствующее сообщение об ошибке.

Фундаментальное различие между методами POST и PUT заключается в различном значении поля URI-Запроса. Для метода POST данный URI указывает ресурс, который будет управлять информацией, содержащейся в теле запроса, как неким придатком. Ресурс может быть обрабатывающим данные процессом, шлюзом в какой-нибудь другой протокол, или отдельным ресурсом, допускающим аннотации. В противоположность этому, URI для запроса PUT идентифицирует информацию, содержащуюся в «Содержание-Запроса». Использующий запрос PUT точно знает какой URI он собирается использовать, и получатель запроса не должен пытаться применить этот запрос к какому-нибудь другому ресурсу.

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

Метод LINK устанавливает взаимосвязи между существующим ресурсом, указанным в URI-Запроса, и другими существующими ресурсами. Отличие метода LINK от остальных методов, допускающих установление ссылок между документами, заключается в том, что метод LINK не позволяет передавать в запросе «Тело-Запроса», и в том, что в результате работы данного метода не создаются новые ресурсы.

Метод UNLINK удаляет одну или более ссылочных взаимосвязей для ресурса, указанного в URI- Запроса. Эти взаимосвязи могут быть установлены с помощью метода LINK или какого-нибудь другого метода, поддерживающего заголовок «Link». Удаление ссылки на ресурс не означает, что ресурс прекращает существование или становится недоступным для будущих ссылок.

Для обработки HTTP запросов был разработан фильтр, реализованный в функции FilterHTTP.

7 Портирование драйвера на 64-битную систему

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

При первом запуске компилятора, генерируется много предупреждений о несоответствии типа, например:

«Warning C4311: 'type cast' : pointer truncation from 'unsigned char *' to 'unsigned long»

Эти предупреждения необходимо использовать в качестве руководства, чтобы сделать код надежнее. Желательно исключить все предупреждения.

Например, следующий код может спровоцировать Warning C4311:

Buffer = (PUCHAR) srbControl;

(ULONG) + = srbControl-> HeaderLength;

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

Buffer = (PUCHAR) srbControl;

(ULONG_PTR) + = srbControl-> HeaderLength;

На рисунке 7.1 показано, что компилятор определяет следующие макросы для идентификации платформы.

Рисунок 7.1 – Макросы для идентификации платформы

Драйвера режима ядра должны проверять размер любого буфера ввода-вывода, переделанного из приложения пользователя. Если 32-разрядное приложение передает буфер, содержащий типы данных с указателем точности на 64-битный драйвер, и не происходит транкинг, драйвер будет ожидать, что буфер будет больше, чем есть на самом деле. Это связано с тем, что точность указателя составляет 32 бита в 32-битной системе, и 64 бита в 64-битной системе. Например, рассмотрим следующее определение структуры:

typedef struct _DRIVER_DATA

{
HANDLE Event;
UNICODE_STRING ObjectName;
} DRIVER_DATA;

В 32-битной Windows размер структуры DRIVER_DATA составляет 12 байтов (рисунок 7.2).

Рисунок 7.2 – Структура DRIVER_DATA

В 64-разрядной версии Windows размер структуры DRIVER_DATA составляет 24 байта (рисунок 7.3). (Требуется дополнительные 4 байта, чтобы можно было выровнять по 8-байтовой границе.)

Рисунок 7.3 – Структура DRIVER_DATA в 64-битной системе

Если 64-битный драйвер получает 12 байтов DRIVER_DATA, ожидая при этом 24 байта, проверка размера не будет выполнена. Чтобы предотвратить это, драйвер должен определить, была ли структура DRIVER_DATA отправлена 32-битным приложением, если да, то выполнить его надлежащим образом.

Например, приведенная выше структура DRIVER_DATA может быть определена следующим образом:

Typedef struct _DRIVER_DATA32

{

VOID * POINTER_32 Event;

UNICODE_STRING32 ObjectName;

} DRIVER_DATA32;

Поскольку в ней содержатся только типы данных с фиксированной точностью, эта новая структура имеет такой же размер в 32-разрядной Windows и 64-разрядной Windows (Рисунок 7.4).

Рисунок 7.4 – Структура DRIVER_DATA

Следующий пример показывает, как изменить 32-разрядный драйвер на 64-битный, добавив поле 64Bit в управляющий код IOCTL.

Пример драйвера для 32-битной системы:

Header File

#define REGISTER_FUNCTION 0 // Define the IOCTL function code

#define IOCTL_REGISTER CTL_CODE(FILE_DEVICE_UNKNOWN, \
REGISTER_FUNCTION, METHOD_BUFFERED, FILE_ANY_ACCESS)

typedef struct _IOCTL_PARAMETERS {
PVOID Addr;
SIZE_T Length;
HANDLE Handle;
} IOCTL_PARAMETERS, *PIOCTL_PARAMETERS;

DeviceControl Dispatch Routine

NTSTATUS
TestdrvDeviceControl(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PIO_STACK_LOCATION irpSp;
NTSTATUS status;
PIOCTL_PARAMETERS params;
IOCTL_PARAMETERS LocalParam;
PIOCTL_PARAMETERS_32 params32;

//
//Get a pointer to the current parameters for this request. The
//information is contained in the current stack location.
//
irpSp = IoGetCurrentIrpStackLocation(Irp);
//
// Case on the device control code
//
switch (irpSp->Parameters.DeviceIoControl.IoControlCode) {
case IOCTL_REGISTER:
params = (PIOCTL_PARAMETERS)
(Irp->AssociatedIrp.SystemBuffer);
if (irpSp->Parameters.DeviceIoControl.InputBufferLength <
sizeof(IOCTL_PARAMETERS)) {
status = STATUS_INVALID_PARAMETER;
} else {
RtlCopyMemory(&LocalParam, params,
sizeof(IOCTL_PARAMETERS));
/* Handle the ioctl here */
status = STATUS_SUCCESS;
}
Irp->IoStatus.Information = 0;
break;
//
// Unrecognized device control request
//
default:
Irp->IoStatus.Information = 0;
status = STATUS_INVALID_PARAMETER;
break;
}
//
// If status is pending, mark the IRP pending and start the
// request in a cancelable state. Otherwise, complete the IRP.
//
Irp->IoStatus.Status = status;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return(status);
}

Ниже приведена 64-разрядная версия драйвера:

Header File

#define REGISTER_FUNCTION 0 // Define the IOCTL function code

#ifdef _WIN64
#define CLIENT_64BIT 0x800
#define REGISTER_FUNCTION 0
#define IOCTL_REGISTER CTL_CODE(FILE_DEVICE_UNKNOWN, \
CLIENT_64BIT|REGISTER_FUNCTION, METHOD_BUFFERED, FILE_ANY_ACCESS)
#else
#define IOCTL_REGISTER CTL_CODE(FILE_DEVICE_UNKNOWN, \
REGISTER_FUNCTION, METHOD_BUFFERED, FILE_ANY_ACCESS)
#endif

typedef struct _IOCTL_PARAMETERS {
PVOID Addr;
SIZE_T Length;
HANDLE Handle;
} IOCTL_PARAMETERS, *PIOCTL_PARAMETERS;

DeviceControl Dispatch Routine

#ifdef _WIN64
#define IOCTL_REGISTER_32 CTL_CODE(FILE_DEVICE_UNKNOWN, \
REGISTER_FUNCTION, METHOD_BUFFERED, FILE_ANY_ACCESS)
#endif
.
.
.
#ifdef _WIN64
typedef struct _IOCTL_PARAMETERS_32 {
VOID*POINTER_32 Addr;
INT32 Length;
VOID*POINTER_32 Handle;
} IOCTL_PARAMETERS_32, *PIOCTL_PARAMETERS_32;
#endif
.
.
.
NTSTATUS
TestdrvDeviceControl(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PIO_STACK_LOCATION irpSp;
NTSTATUS status;
PIOCTL_PARAMETERS params;
IOCTL_PARAMETERS LocalParam;
PIOCTL_PARAMETERS_32 params32;

//
//Get a pointer to the current parameters for this request. The
//information is contained in the current stack location.
//
irpSp = IoGetCurrentIrpStackLocation(Irp);
//
// Case on the device control code
//
switch (irpSp->Parameters.DeviceIoControl.IoControlCode) {
#ifdef _WIN64
case IOCTL_REGISTER_32:
params32 = (PIOCTL_PARAMETERS_32)
(Irp->AssociatedIrp.SystemBuffer);
if (irpSp->Parameters.DeviceIoControl.InputBufferLength <
sizeof(IOCTL_PARAMETERS_32)) {
status = STATUS_INVALID_PARAMETER;
} else {
LocalParam.Addr = params32->Addr;
LocalParam.Handle = params32->Handle;
LocalParam.Length = params32->Length;
/* Handle the ioctl here */
status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
}
break;
#endif
case IOCTL_REGISTER:
params = (PIOCTL_PARAMETERS)
(Irp->AssociatedIrp.SystemBuffer);
if (irpSp->Parameters.DeviceIoControl.InputBufferLength <
sizeof(IOCTL_PARAMETERS)) {
status = STATUS_INVALID_PARAMETER;
} else {
RtlCopyMemory(&LocalParam, params,
sizeof(IOCTL_PARAMETERS));
/* Handle the ioctl here */
status = STATUS_SUCCESS;
}
Irp->IoStatus.Information = 0;
break;
//
// Unrecognized device control request
//
default:
Irp->IoStatus.Information = 0;
status = STATUS_INVALID_PARAMETER;
break;
}
//

// If status is pending, mark the IRP pending and start the
// request in a cancelable state. Otherwise, complete the IRP.
//
Irp->IoStatus.Status = status;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return(status);
}

8 Установка драйвера

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

Мой драйвер является NDIS Miniport драйвером, для таких драйверов в системе есть встроенные средства установки и настройки драйверов. Чтобы запустить мастер установки необходимо открыть свойства любого сетевого соединения в окне «Сетевые подключения» (рисунок 8.1).

Рисунок 8.1 – Окно сетевые подключения

В открывшихся свойствах на закладке «Общие» (рисунок 8.2.1) или «Сеть» (рисунок 8.2.2), в зависимости от типа сетевого подключения, необходимо нажать кнопку «Установить» для запуска мастера установки сетевых компонентов.

1)

2)

Рисунок 8.2 – Закладка «Общие» для сетевой карты(1) и Закладка «Сеть» для виртуальных соединений и модемов(2)

Характеристики

Список файлов ВКР