УСТРОЙСТВО, СПОСОБ И ПРОГРАММА СВЯЗИ ПО СЕТИ
DEVICE, METHOD AND PROGRAMME FOR NETWORK COMMUNICATION

Техническая область
Настоящее изобретение относится к функции связи, работающей в персональном компьютере, например, для осуществления связи с устройством в сети. В частности, изобретение относится к функции связи, использующей в качестве протокола связи IPv6 (Протокол Интернет версии 6).
Предыдущий уровень техники
В ответ на происходящее исчерпание доступных в текущем протоколе Интернет (IPv4) адресов на практике начинают применять IPv6 как протокол Интернет следующего поколения, улучшенный для увеличения адресного пространства, обеспечения дополнительной безопасности и передачи данных в соответствии с приоритетом. Спецификации протокола IPv6 таковы, что одному сетевому интерфейсу можно присвоить множество адресов. Например, из адресов, которые можно присвоить, известны локальный канальный адрес одноадресной передачи (обозначаемый ниже как "локальный канальный адрес") и глобальный адрес для одноадресной передачи (обозначаемый ниже как "глобальный адрес"). Более того, поскольку множество адресов можно присвоить как глобальные адреса, существуют случаи, когда в отношении узла в сервере DNS (системы доменных имен) зарегистрирован адрес IPv4 и множество адресов IPv6.
Обычно, для идентификации связывающейся стороны используют FQDN (полное доменное имя), обычно обозначаемое как "имя". Необходимо отметить, что FQDN представляет собой имя узла или имя домена, указанное от корня по иерархической структуре домена DNS. Ниже FQDN будет обозначаться просто как "имя". Когда у сервера DNS запрашивают о двоичном адресе, указывая имя, существуют случаи получения множества адресов IPv6. В том чтобы с персонального компьютера, служащего источником запроса, все эти адреса были доступны, необходимости нет. В связи по протоколу TCP, использующей IPv6, делают попытку последовательного подключения к множеству адресов, полученных в результате разрешения имени с использованием DNS, и адрес, превалирующий на момент соединения, используют в качестве адреса стороны. Со связью по протоколу UDP (протокол пользовательских датаграмм), использующей IPv6, приложение должно проверить доступность, используя способ, такой как переотправку пакета по отношению к стороне связи. Соответственно, практически таким же образом, как и в связи по протоколу TCP, должны быть сделаны последовательные попытки передачи пакета на множество адресов. Таким образом, связь по протоколу IPv6 предполагает увеличение объема передаваемых по сети данных и времени попыток до установления соединения, в сущности, вследствие факта использования множества адресов.
Аналогично, как локальные адреса, противостоящие адресу стороны, осуществляющей связь, существует множество локальных адресов, когда определен адрес стороны, осуществляющей связь, в соответствии с алгоритмом, определенным в RFC 3484 ["Выбор адреса по умолчанию для протокола Интернет версии 6 (IPv6)"]. Поскольку этот алгоритм выбора адреса выполняется внутри программы, обычно обозначаемой как "стек протоколов", который является почти операционной системой, программа приложение не может участвовать в отношении выбранного локального адреса.
Поскольку для каждых двух конечных точек связи существует множество адресов IPv6, в том случае если осуществляют связь, в частности, по UDP протоколу, возникает ситуация, описанная ниже. Предположим, что конечные точки связи A и B каждая обладает тремя своими собственными IPv6 адресами, и этими адресами являются Addr_A1, Addr_A2, Addr_A3 и Addr_B1, Addr_B2, Addr_B3 соответственно. Допустим, что среди адресов, принадлежащих конечной точке связи B, в DNS зарегистрированы два адреса, Addr_B1 и Addr_B2.
В случае когда конечная точка связи A начинает связь с конечной точкой B, как проиллюстрировано на Фиг.3A, первая конечная точка связи A указывает имя конечной точки связи B (в этом документе именем будет являться "конечная точка связи B") и запрашивает (запросом) сервер DNS о разрешении имени. DNS сервер отправляет обратно (отвечает) два адреса (Addr_B1 и Addr_B2) как результат разрешения имени.
Конечная точка связи A, получившая результат разрешения имени, передает запрос на Addr_B1 и достигает конечной точки связи B. Конечная точка связи B отправляет обратно ответ, соответствующий запросу. Однако в этот момент конечной точке связи известно, что адрес Addr_A1 является адресом источника передачи, и, следовательно, она направляет свой ответ на этот адрес. Когда это выполнено, выполняется упомянутый выше алгоритм выбора адреса, определенный в RFC 3484, и бывают случаи, когда из трех адресов, принадлежащих конечной точке связи B, вместо адреса Addr_B1 в качестве оптимального выбирают адрес Addr_B3. Таким образом, ответ от конечной точки связи B отправляют с адреса Addr_B3 на Addr_A1 конечной точки связи A. Таким образом, возникает ситуация, в которой с точки зрения конечной точки связи A данные ей были присланы с неизвестного адреса.
Существуют случаи, когда, если подтверждено, что сторона, на которую конечная точка связи A передала запрос, - это строго конечная точка связи B, то данные с неизвестного адреса можно определить как ответ, отправленный с конечной точки связи B. Однако необходимо понимать, что такое определение невозможно, если рассматривать случай, когда, как показано на Фиг.3B, конечная точка связи A посылает практически одновременно запросы на две стороны с конечными точками связи B и C. Допустим, что адресами конечных точек связи A, B и C с Фиг.3B являются Addr_A1, Addr_A2, Addr_A3; Addr_B1, Addr_B2, Addr_B3; и Addr_C1, Addr_C2, Addr_C3 соответственно. Далее, допустим, что среди адресов, принадлежащих конечной точке связи B, в DNS зарегистрированы Addr_B1 и Addr_B2, и такими адресами конечной точки C являются Addr_C1 и Addr_C2. Также предположим, что конечная точка связи A запрашивает сервер DNS касательно имен конечных точек связи B и C, конечная точка связи B отправляет ответ с адреса Addr_B3 на Addr_A1, и конечная точка связи C направляет ответ с Addr_C3 на Addr_A1.
Таким образом, конечная точка связи A принимает данные с неизвестных адресов Addr_B3 и Addr_C3. Конечная точка связи A не может определить, с каких из точек B и C как ответные данные были приняты эти два объекта данных. В случае протокола, такого как IPv4, в котором отправку ответа всегда можно ожидать с адреса адресата передачи запроса, такой проблемы возникнуть не может, поскольку передающую сторону можно идентифицировать набором адресов, которые включают в себя номера портов на обоих конечных точках связи. В случае когда адрес источника передачи ответного пакета не совпадает с адресом адресата пакета с запросом, то при этих обстоятельствах возникает проблема безопасности, конкретно, невозможность выполнить фильтрацию пакетов по адресу для отказа в приеме.
Точнее, поскольку существует возможность того, что пакет данных, отправленный с неизвестного адреса, будет представлять собой легитимный ответ на пакет запроса, его не фильтруют и нельзя отбросить. Это значит, что все и любые пакеты нужно принимать.
С целью улучшения увеличения количества передаваемых данных и задержки в обработке, сопровождающей разрешение имени в сервере DNS, существует способ определения на основании предыдущего опыта, какой протокол должен быть использован для осуществления доступа к серверу, в котором зарегистрированы адреса IPv4 и IPv6 (смотри публикацию патента Японии номер 2007-19612). Предыдущий уровень техники, описанный в публикации патента Японии номер 2007-19612, в основном предполагает ситуацию, в которой протоколы IPv4 и IPv6 смешаны. В нем соотносят и кешируют протокол IP, с помощью которого удавалось ранее осуществлять связь с серверным процессом, к которому производилась попытка получения доступа, с серверным процессом и попыткой использовать этот протокол IP и соответствующий адрес при следующей попытке осуществления доступа. Этот предыдущий уровень техники эффективно снижает доступ к серверу DNS и уменьшает ненужные попытки доступа к адресам в том случае, если серверный процесс не ожидает на всех адресах протоколов, зарегистрированных в сервере DNS.
Однако в ситуации, в которой ответ от серверного процесса отправляют с неизвестного адреса, кеширование не выполняется, и проблемы, описанные ниже, нельзя решить даже при помощи изобретения, описанного в публикации патента Японии номер 2007-19612.
1. Обычно, ответные данные с адреса, отличающегося от адреса, выбранного в качестве адресата передачи, нужно принимать. Таким образом, существует проблема безопасности, конкретно, необходимость отключения пакетной фильтрации.
2. С приложениями, которые осуществляют связь, используя адреса обоих протоколов IPv4 и IPv6, увеличивается количество раз, которые запрашивают сервер DNS о разрешении имен. Это увеличивает объем передаваемых данных и задерживает время ответа.
3. В случае когда в сервере DNS зарегистрировано множество адресов IPv6 для одной конечной точки связи, существует вероятность того, что передачу пакета осуществят с использованием всего множества адресов. Другими словами, объем передаваемых данных увеличивается.
Сущность изобретения
Настоящее изобретение решает проблемы, изложенные выше. Для достижения решения настоящее изобретение предоставляет устройство обмена данными для осуществления связи через сеть с сетевым устройством, которому можно присвоить множество адресов на одно имя, включающее в себя: средство получения для получения адреса, соответствующего имени адресата передачи; средство передачи для передачи этих данных передачи вместе с идентификационной информацией, идентифицирующей данные передачи для полученного адреса; средство приема для приема ответных данных, обладающих идентификационной информацией, соответствующей данным передачи; средство определения для определения на основании идентификационной информации, являются ли принятые ответные данные ответом на данные передачи; и средство обработки ответа для сброса ответных данных в том случае, если определено, что ответные данные не являются ответом на данные передачи, и доставки данных, содержащихся в ответных данных, к источнику, запрашивающему передачу данных, если определено, что ответные данные являются ответом на данные передачи.
Результат, предоставляемый настоящим изобретением, заключается в том, что упомянутые выше проблемы решаются приложением. Точнее, можно решить проблему безопасности, конкретно вызванную тем, что пакетная фильтрация должна быть снята. Дополнительно увеличение объема передаваемых данных и задержку в ответе можно предотвратить даже в случае приложения, которое осуществляет связь с использованием обоих IPv4 и IPv6 протоколов. Увеличение объема передаваемых данных можно подавить даже в том случае, когда на сервере DNS для одной конечной точки связи зарегистрировано множество IPv6 адресов.
Дополнительные характерные черты настоящего изобретения станут очевидны из следующего описания примерных вариантов осуществления со ссылкой на приложенные чертежи.
Краткое описание чертежей
На Фиг.1 приведена блок-схема драйвера принтера в соответствии с вариантом осуществления настоящего изобретения.
На Фиг.2 приведена блок-схема, иллюстрирующая конфигурацию персонального компьютера в соответствии с вариантом осуществления изобретения.
На Фиг.3A приведена диаграмма, иллюстрирующая отношение между конечными точками связи и сервером DNS, обрабатывающим адреса IPv6.
На Фиг.3B приведена диаграмма, иллюстрирующая отношение между адресами, используемыми среди множества конечных точек связи, обрабатывающих адреса IPv6.
На Фиг.4A приведена блок-схема, иллюстрирующая обработку получения данных в варианте осуществления изобретения.
На Фиг.4B приведена блок-схема, на которой проиллюстрирована обработка инициации запроса в варианте осуществления изобретения.
На Фиг.4C приведена блок-схема, иллюстрирующая обработку приема ответа в варианте осуществления изобретения.
На Фиг.5 приведена блок-схема, иллюстрирующая процесс приемопередачи в варианте осуществления изобретения.
На Фиг.6A приведена блок-схема, иллюстрирующая обработку получения адреса другой стороны, осуществляющей связь, в варианте осуществления изобретения.
На Фиг.6B приведена блок-схема, иллюстрирующая обработку регистрации адреса другой стороны, осуществляющей связь, в варианте осуществления изобретения.
На Фиг.7A приведена диаграмма, иллюстрирующая структуру данных запроса в варианте осуществления изобретения.
На Фиг.7B приведена диаграмма, иллюстрирующая структуру данных ответа в варианте осуществления изобретения.
Описание вариантов осуществления изобретения
На Фиг.2 приведена блок-схема, иллюстрирующая конфигурацию персонального компьютера, служащего устройством обмена данными, который выполняет загрузку приложения, когда настоящее изобретение применяют к драйверу принтера. Персональный компьютер, в котором установлен драйвер принтера, работает в качестве устройства управления принтером для управления принтером. Операционная система персонального компьютера выполняется CPU 3 после сохранения в средстве хранения, которым могут являться любое из RAM 4, жесткого диска 5 или носителей хранения в дисковом накопителе, описанном позже. Операционная система представляет экран на устройстве отображения 6 в ответ на ввод пользователя с блока ввода 7 и информирует драйвер принтера об этом вводе. Операционная система управляет блоком связи 8, управляет периферийным устройством 9 в дополнение к периферии, подключенной к блоку связи 8, вводит и выводит сигналы с и на драйвер принтера. Примерами периферийных устройств, управление которыми можно осуществлять, являются карта расширения PC, различные дисковые накопители, принтер и сетевая карта и т.п. Операционная система также предоставляет функцию файловой системы. Носители файлового хранения не ограничены жестким диском 5 и RAM 4 с Фиг.2, но также включают в себя внешние устройства накопителей, включая другой персональный компьютер в сети, подключенный при помощи блока связи 8. Операционная система и драйвер принтера доставляют и принимают данные с и на группу аппаратных модулей, взаимосоединенных через системные шины персонального компьютера 1, 2.
Драйвер принтера получает доступ к ресурсам персонального компьютера через интерфейс программирования приложений (API), предоставленный операционной системой, и использует функции, предоставленные операционной системой. Драйверу принтера, который загружен в программе приложения, доставляют данные для печати и транслируют данные для печати в язык, который понятен принтеру. Это представляет собой основную обработку, выполняемую драйвером принтера. Дополнительно, драйвер принтера предоставляет функцию для приема и отображения для пользователя статуса таких устройств, как блок брошюрования, блок стопоукладчика и лотка для бумаги, которыми оборудован принтер. Дополнительно, драйвер принтера предоставляет функцию для получения и отображения списка заданий печати, которые накоплены в принтере и ожидают печати.
Драйвер принтера выполняется CPU 3 после сохранения в средстве хранения, которым могут являться любое из RAM 4, жесткого диска 5 или носителей хранения в дисковом накопителе, описанном позже. Дополнительно, драйвер принтера обращается к файлам, сохраненным на файловой системе, предоставленной операционной системой. Ниже в описании, относящемся к конфигурации и работе драйвера принтера, будет пропущено подробное описание, относящееся к функции трансляции данных для печати. Драйвер принтера в соответствии с этим вариантом осуществления изобретения предполагает, что устройство, такое как сетевой принтер или копир, представляет собой сетевое устройство на другом конце связи, указанном пользователем. Устройство, такое как сетевой принтер или копир, будет ниже обозначено как просто "принтер". Ниже детально описана функция для доступа к принтеру по сети, получения названия модели принтера, списка функций, которыми оборудован принтер, списка заданий на печать, поступивших в принтер, и отображение этой информации на устройстве отображения 6, показанном на Фиг.2.
На Фиг.1 приведена блок-схема, иллюстрирующая конфигурацию драйвера принтера 10 в соответствии с настоящим изобретением. Драйвер принтера 10 транслирует данные, созданные программой приложения или тому подобным, в язык описания принтера, который может понять и исполнить указанным пользователем принтер, и передает транслированные данные на этот принтер. Несмотря на то что, обычно, переданные данные обозначают как данные передачи, по отношению к вышеупомянутым транслированным данным, отправленным на принтер, будет использован термин "данные печати". Драйвер принтера 10 включает в себя блок отображения 50, блок ввода 60, логику доступа 20, транспортный блок 30 и логику драйвера 40. Сначала будут определены три функциональных блока драйвера принтера 10.
Логика драйвера 40 представляет из себя функциональный блок для указания имени принтера для логики доступа 20 и инструктирования логики доступа для получения информации. Логика драйвера 40 выполняет обработку для транслирования данных печати в драйвере принтера 10 и отображает экран на устройстве отображения персонального компьютера. Дополнительно, логика драйвера 40 управляет средством выбора принтера, при помощи которого пользователь выбирает принтер, и средством специфицирования для получения функций выбранного принтера и проводит отображение на экране информации, полученной от принтера. Дополнительно, логика драйвера 40 выполняет обработку для указания имени принтера для логики доступа 20, описанной ниже, запрашивая получение желаемой информации и получая результат.
Логика доступа 20 представляет собой блок, исполняющий обработку для создания данных запроса, на основании данных передачи, указывая адресата передачи запроса, обозначенной доменным именем или именем узла (т.е. FQDN) и запрашивая транспортный блок 30 о выполнении передачи запроса. Несмотря на то что адресат передачи запроса можно указывать не только при помощи FQDN, но и в виде двоичного адреса IPv4 или IPv6 (протокола Интернет версии 6) или имени компьютера и т.п., логика доступа 20 указывает, по меньшей мере, FQDN.
Транспортный блок 30 представляет собой функциональный блок для отправки запрашиваемых данных запроса на запрошенный адресат передачи, приема ответа на этот запрос и доставки ответа в логику доступа 20. Предполагается, что транспортный блок 30 не обладает каким-либо знанием, относящимся к содержанию запроса, передача которого была запрошена, как и содержанию ответа. Дополнительно, транспортный блок 30 запрашивает сервер DNS с целью специфицирования двоичного адреса адресата передачи, указанного при помощи FQDN.
Драйвер принтера 10 осуществляет доступ на существующий в сети сервер DNS. Драйвер принтера 1 указывает серверу DNS FQDN принтера, являющийся целью связи для драйвера принтера, и получает как ответ адрес, присвоенный этому принтеру.
Блок ввода 60 принимает ввод от пользователя при помощи блока ввода 7 с Фиг.2 и доставляет ввод в логику драйвера 40. В качестве информации ввода доставляют FQDN принтера, являющегося стороной связи, и команду начать получение адреса. Блок отображения 50 выполняет обработку для создания данных для отображения и для отображения этих данных на устройстве отображения 6 с Фиг.2. Отображенное содержимое включает в себя информацию, полученную от принтера, а конкретно название модели принтера, список функций, которыми оборудован принтер, и список заданий на печать из принтера.
Логика драйвера 40 доставляет логике доступа 20 FQDN принтера и инструкцию начать получение адреса, каковые доставляют из блока ввода 60.
Логика ввода 20 включает в себя блок 201 генерирования ID запроса, блок хранения 202, хранящий отношение между именем стороны, осуществляющей связь, и ID запроса, блок хранения 203, хранящий отношение между ID запроса и запросом, и блок управления 200. Когда применяют инструкцию начать получение адреса, блок управления 200 посылает блоку генерирования ID запроса 201 запрос на генерирование ID запроса. В ответ на запрос от блока управления 200 блок генерирования ID запроса 201 генерирует уникальный ID запроса и отправляет ID обратно. ID запроса использует ID, циклический на сравнительно длинном периоде. В результате возможность того, что в то же время, что и отдельный запрос на это же устройство или запрос на другой принтер, будет использован ID запроса, идентичный сгенерированному при исполнении передачи на определенный принтер, очень мала. Напротив, в качестве периода для ID запроса выбирают период, достаточно длинный для того, чтобы в одной системе не использовались идентичные IDs. Существует возможность того, что единичный ID запроса будет использован на протяжении максимального промежутка времени, эквивалентного [количество адресов, зарегистрированных в DNS по отношению к имени узла (в этом примере принтера) адресата передачи] * (время ожидания ответа) + (времени пробуждения от сна) + время, требуемое для ответа. Если эту протяженность времени применяют в качестве максимального времени использования ID, то уникальность ID запроса будет поддержана в том случае, если соблюдают следующее условие (период ID запроса) > (максимальное время использования ID) / (средний интервал времени, в течение которого генерируется запрос на передачу).
Блок управления 200 доставляет FQDN стороны, осуществляющей связь, и ID запроса в блок хранения 202, который сохраняет их соотнесенными друг с другом. Блок хранения 202 также обладает функцией, которая при указании ID запроса ищет соотнесенный FQDN и отправляет обратно найденный FQDN. Блок управления 200 доставляет ID запроса и данные запроса в блок хранения 203, который сохраняет их соотнесенными друг с другом. Блок хранения 203 также обладает функцией, которая при указании ID запроса ищет соотнесенные данные запроса и отправляет обратно найденные данные запроса.
Блок управления 200, управляющий блоком генерации ID 201, блоком хранения 202, блоком хранения 203 и транспортным блоком 30, получает необходимую информацию от принтера со стороны, осуществляющей связь.
Управляющий блок не осведомлен о подробностях месторасположения на сети (адресах) внешнего сервера DNS 70 и принтера 80. Управляющий блок 200 создает данные протокола, обозначаемые как данные запроса и определенные соглашением с принтером. В данные протокола включен ID запроса, представляющий собой уникальный ID для уникальной идентификации стороны, осуществляющей связь. Данные запроса, представляющие собой содержимое передачи и имя (FQDN) стороны, осуществляющей связь, представляющее собой адресат передачи, доставляют из блока управления 200 в транспортный блок 30, и последний запрашивают о выполнении передачи.
Транспортный блок 30 включает в себя блок разрешения имен 301, блок хранения 304, сохраняющий отношение между именем стороны, осуществляющей связь, и адресом, блок передачи запроса 302 и блок приема ответа 303. Блок передачи запроса 302 принимает как ввод данные запроса и имя, т.е. FQDN, принтера, являющегося адресатом передачи. Затем блок передачи запроса 302 запрашивает блок разрешения имен 301 о конвертации принятого FQDN в адрес. Блок разрешения имен 301 организует поиск блоком хранения 304 адреса, соотнесенного с доставленным из блока передачи запроса 302 FQDN. Если связанный адрес найден, блок разрешения имен 301 доставляет этот адрес в блок передачи запроса 302. Фактически, блок хранения 304 функционирует как часть исполнения для блока разрешения имен 301 для получения адреса из FQDN и отсылки адреса обратно. Таким образом, блок передачи запроса 302 получает адрес (адрес стороны, осуществляющей связь), соответствующий FQDN адресата передачи. Адрес, указанный для разрешения имени, может быть как адресом IPv4, так и адресом IPv6. Как упомянуто ранее, в случае IPv6 одному имени (FQDN) можно присвоить множество адресов.
Блок передачи запроса 302 использует UDP (протокол пользовательских датаграмм) для передачи данных запроса, запрошенных по отношению к полученному адресу стороны, осуществляющей связь. В случае когда из блока разрешения имен 301 возвращено множество адресов, обработка выполняется по отношению к каждому адресу для переотправки данных запроса, если по прошествии фиксированного периода времени, следующего за передачей данных запроса, не получен ответ.
Блок приема ответа 303 предоставляет функцию по приему данных ответа с принтера и доставке данных ответа логике доступа 20 в качестве данных ответа. Также блок приема ответа 303 получает адрес источника передачи данных ответа и доставляет этот адрес вместе с данными ответа. Необходимо отметить, что принтер передает данные ответа, используя UDP. Запрос соотносят при помощи ID запроса, содержащегося в пакете.
Со ссылкой на Фиг.7A и 7B будут описаны пакетные структуры данных запроса 701 и данных ответа 702, которыми обмениваются драйвер принтера 10 и принтер. На Фиг.7A проиллюстрированы данные запроса 701, которые отправляют с драйвера принтера 10 на принтер. Данные запроса 701 включают в себя заголовок пакета фиксированной длины и переменной длины тело. В том, что касается расстановки полей, заголовок пакета данных ответа 702 такой же. Однако в данных запроса 701 в поле "ТИП" указывают числовое значение "0", указывающее на запрос, в то время как в поле "ТИП" заголовка пакета ответа 702 указывают числовое значение "1", указывающее на ответ. Общий объем (количество октетов) данных запроса 701 или 702 содержат в поле пакетного заголовка "РАЗМЕР ПАКЕТА". ID запроса, указанный на стороне, создавшей данные запроса 701, также содержится в соответствующем ответе в поле "ID". То есть ID запроса, содержащийся в соответствующих данных запроса, записывают не изменяя в поле заголовка пакета "ID" данных ответа 702. Тело запроса обладает полем "КОМАНДА", которое указывает желаемое содержимое обработки принимающей стороне. Запросы, такие как запросы о названии модели устройства, запрос списка функций, которыми оборудовано устройство, и запрос списка заданий, содержащихся в устройстве, определены как типы обработки содержимого, указанного в поле "КОМАНДА". Параметр, принятый для каждой команды, указан в поле тела запроса "ПАРАМЕТР".
С другой стороны, тело ответа обладает полем "КОМАНДА", указывающим на обработанное содержимое. Содержимое "КОМАНДА", содержащееся в соответствующих данных запроса, сохраняют в этом поле, не изменяя. Значение, обозначающее результат исполнения обработки, содержится в поле "РЕЗУЛЬТАТ" тела ответа. Определены значения, обозначающие результат обработки, такие как успех, неправильный параметр или ошибка при исполнении.
Со ссылкой на блок-схемы, показанные на Фиг. с 4A по 6B, будет описана обработка, выполняемая логикой доступа 20 и транспортным блоком 30. На Фиг.4A приведена блок-схема, иллюстрирующая процесс для получения данных с принтера. Это представляет собой главную функцию логики доступа 20.
На этапе S10 выполняют обработку выпуска запроса для указания принтера адресату передачи и передачи данных запроса на указанный принтер. На этапе S20 выполняют обработку получения ответа с указанного принтера вместе с адресом стороны передачи. На этапе S30 FQDN, представляющее собой имя адресата передачи (сторону связи), указанное вместе с данными запроса и адресом (IP адресом, например), принятым вместе с данными ответа, доставляют в транспортный блок 30. В результате транспортный блок 30 соотносит имя (FQDN) стороны, осуществляющей связь, с адресом.
Обработка получения данных с этапа S10 включает в себя обработку этапов с S10 по S13, как показано на Фиг.4B. Этап S11 представляет собой этап создания данных запроса, передаваемых на принтер. Конкретнее, обработка этапа S11 создает данные запроса, помещая ID запроса в пакет запроса. ID запроса был сгенерирован в блоке генерации ID 201 и представляет собой уникальный ID запроса, по меньшей мере, в настоящий момент времени.
Этап S12 представляет собой этап соотнесения по соотнесению стороны, осуществляющей связь, и данных запроса. Здесь стороной связи является имя (FQDN) принтера, и содержимое данных запроса копируется и сохраняется в блоке хранения 203 с Фиг.1 до получения ответа. На этапе S12 пакет запроса соотносят с ID запроса и сохраняют в блоке хранения 203.
На этапе S13 созданные данные запроса 701 доставляют в транспортный блок 30 вместе с именем (FQDN) принтера, представляющего собой сторону связи, и транспортный блок 30 запрашивают о передаче этой информации. Одновременно с запросом о передаче имя принтера и ID запроса соотносят и сохраняют в блоке хранения 202.
Необходимо отметить, что данные запроса, per se, включают в себя ID запроса. Это означает что, например, на этапе S13 имя стороны, осуществляющей связь, и пакет запроса можно соотнести и сохранить без сохранения ID запроса и пакета запроса на этапе S12. Данные запроса, обладающие определенным ID запроса, можно извлечь даже в том случае, если применяют такую компоновку.
Далее описана обработка приема ответа на этапе S20 с Фиг.4A, а конкретнее, обработку ответа. На Фиг.4C приведена блок-схема, на которой подробно показана обработка приема ответа. Обработка приема ответа включает в себя обработку этапов с S21 по S23. Этап S21 представляет собой этап по приему данных ответа 702 из транспортного блока 30. Логика доступа 20 периодически запрашивает транспортный блок 20 о поступлении данных ответа и принимает данные ответа, если они приняты. Если данные пока не приняты, логика доступа 20 запрашивает через регулярные интервалы транспортный блок 30 о приходе данных.
Если данные можно принять, одновременно получают адрес (IP адрес) источника, с которого передавались принятые данные. Эту информацию транспортный блок 30 может получить из стека протоколов, включенного в операционную систему, и это будет описано позднее. Управление затем передается на этап S22.
На этапе S22 из заголовка пакета данных ответа 702 извлекают ID запроса. Используя извлеченный ID запроса как ключ, запрашивают блок хранения 203 с Фиг.1 и получают данные запроса, соотнесенные с ID запроса. Таким образом, сравнивают ID запроса пакета ответа и ID запроса запросов, переданных в прошлом. Эту обработку выполняют для определения факта авторизации данных ответа 702 с принтера как авторизованный ответ на данные запроса 701, отправленные с драйвера принтера 10. Тот факт, что данные запроса обладают ID запроса, содержащимся в данных ответа, служит подтверждением того, что эти данные ответа отправлены обратно с правильной передающей стороны, осуществляющей связь. Таким образом, можно определить, что высока вероятность того, что данные ответа, обладающие ID запроса из переданных данных запроса, являются авторизованным ответом. Поскольку запрос и ответ соотнесены путем сравнения информации, обычно сложно полностью воспрепятствовать фальшивому или ошибочному ответу. По этой причине, определение факта авторизации запроса осуществляют с определенной долей вероятности. Это выполняют аналогичным образом так же, как и в обычной последовательности запроса/ответа. С другой стороны, данные ответа, не обладающие ID запроса переданных данных запроса, можно определить как ответ, не являющийся авторизованным ответом.
Если определено, что ответ не является авторизованным ответом, тоданные ответа отбрасывают без выполнения какого-либо дополнительного анализа содержимого. Как достоинство данной обработки можно реализовать функцию фильтрации для обнаружения и сброса до определенного предела поддельного пакета от злонамеренного иного источника в сети. Затем анализируют и доставляют в блок отображения 50 содержимое данных ответа. Блок отображения 50 создает данные отображения и представляет это отображение на устройстве отображения 6 с Фиг.2.
Этап S23 представляет собой этап поиска имени стороны, осуществляющей связь, на основании ID запроса. Указывают ID запроса, полученного на этапе S22, и обратно в блок хранения 202 отсылают имя (FQDN) стороны, осуществляющей связь, соотнесенной с указанным ID запроса. Полученный FQDN и адрес источника передачи данных ответа, полученный на этапе S21, отправляют обратно на источник вызова и затем завершают обработку приема ответа.
На этапе S30 FQDN принтера, полученное на этапе S20, и адрес этого же принтера подают на ввод и вызывают функцию для соотнесения имени и адреса, выполняемую блоком разрешения имен 301 транспортного блока 30. Блок разрешения имен 301 выполняет обработку с Фиг.6B. Это будет описано позже. Затем данные ответа, соответствующие принятому авторизованному ответу, и соответствующий ID запроса удаляют из блока хранения 203. Далее, по отношению к запросу, для которого не удалось получить корректный ответ, соответствующие данные запроса и соответствующий ID запроса аналогично удаляют из блока хранения 203.
На Фиг.5 и Фиг.6A, 6B приведены блок-схемы, иллюстрирующие обработку, выполняемую транспортным блоком 30. Обработка передачи с Фиг.5 представляет собой обработку, выполняемую транспортным блоком 30, как результат запроса транспортного блока 30 о передаче. Это было описано выше по отношению к обработке логики доступа 20 на этапе S13 с Фиг.4B. Обработка передачи с Фиг.5 обладает этапом S50 и этапами с S60 по S67. Обработка на этапе S50 по получению адреса стороны, осуществляющей связь, будет подробно описана как этапы, показанные на Фиг.6A. На этапе S50 в качестве ввода принимают имя принтера, представляющего собой сторону связи. Собственно, поскольку до передачи запроса существует необходимость преобразования имени стороны, осуществляющей связь, в адрес, предпринимают попытку получить пригодный адрес, осуществляя доступ к обоим или одному из блока хранения 304, хранящего соотнесение между именем стороны, осуществляющей связь, и адресом, и внешнего сервера DNS 70. Эти детали будут описаны со ссылкой на Фиг.6A.
На этапе S51 с Фиг.6A определяют, зарегистрировано ли как ключевое имя, доставленное на ввод блока хранения 304 на этапе S50. Если имя уже было зарегистрировано, то адрес, соотнесенный с именем стороны, осуществляющей связь, извлекают из блока хранения 304 и отсылают обратно источнику вызова. Блок хранения 304 также может обозначаться как "кеш". Если, с другой стороны, имя стороны, осуществляющей связь, не зарегистрировано, то сервер DNS 70 запрашивают о разрешении имени на этапе S52. Когда запрос сделан, разрешение запрашивают для обоих адресов IPv4 и IPv6. В том случае если получают множество адресов, все они отправляются обратно на источник вызова в виде списка (адресного списка). В случае когда драйвер принтера 10 осуществляет доступ к определенному принтеру впервые, на этапе S51 принимается решение "НЕТ", и сервер DNS 70 выполняет разрешение имени. Необходимо отметить, что "кеш", упомянутый на этапе S53, не кеширует результат разрешения имени сервером DNS 70 как есть. Содержимое кеша, а конкретно, блока хранения 304, представляет собой информацию, которую подали на ввод путем обработки регистрации адреса стороны, осуществляющей связь, показанной на Фиг.6B и описанной позднее.
После того как на этапе S50 получили адрес принтера, представляющего собой сторону связи, начиная с этапа S60 с Фиг.5, выполняют обработку передачи запроса и приема ответа. Обработка приемопередачи с Фиг.5, в сущности, включает в себя передачу пакета запроса на полученный адрес стороны, осуществляющей связь, и затем проверки того, что в отведенное для приема время ожидания принят ответ. В том случае когда получают множество пакетов, из них выбирают один и передают его на выбранный адрес. Если в течение определенного периода времени ответ не получен, то, повторяя отправку определенное количество раз (например, два раза) в отношении одного и того же адреса, производятся попытки со всеми адресами, полученными на этапе S50. Эти попытки прекращают, когда ответ не получен несмотря на то, что запрос был передан на все адреса, полученные при разрешении имени.
Теперь шаг за шагом будет описан процесс приемопередачи. На этапе S60 с Фиг.5 определяют, существует ли в списке адресов сторон связи, полученном на этапе S50, еще не обработанный адрес. Это значит, что процесс на этапе S60 включает в себя инкрементирование индекса, указывающего на адрес, с верха списка адресов, и определение существования адреса в точке, в которую был инкрементирован адрес. Если там существует еще не обработанный адрес, то определено, что присутствует адрес, который можно будет получить. Если уже был достигнут нижний конец списка, на этапе S60 принимают решение "НЕТ", и осуществляется выход из процесса, поскольку процесс не может продолжаться далее. Может существовать два случая, в которых на этапе S60 при первом прохождении принимают решение "НЕТ", а именно случай, в котором имя принтера, представляющего собой сторону связи, не зарегистрировано на сервере DNS, и случай, в котором ответ не отправлен обратно в течение определенного времени, поскольку, например, источник питания принтера выключен или принтер выведен из состава сети. В том случае если следующий адрес существует, этот адрес принимают как адрес попытки. В этот момент счетчик для подсчета количества передач возвращают в начальное значение, например ноль. Затем управление передают на этап S61. Здесь, определяют, было ли для каждого адреса превышено прописанное количество попыток передачи. То есть если значение счетчика превосходит прописанное число, то управление возвращают на этап S60 и предпринимают попытку получить следующий адрес.
Если на этапе S61 принимают решение "НЕТ", то на этапе S62 выполняют обработку передачи данных запроса. На этапе S61 обработку выполняет блок передачи запроса 302 транспортного блока 30. На этапе S61 данные запроса, полученные от логики доступа 20, передают на адрес, принятый как объект для попытки на этапе S60.
Затем на этапе S63 система ожидает ответа только в течение прописанного времени ожидания ответа (например, пяти секунд). В том случае если принтер был в состоянии сна, то время ожидания обусловлено добавлением времени, необходимого для процедуры пробуждения и ответа после пробуждения.
На этапе S64 делают попытку получения ответа от принтера. Конкретно, вызывают функцию получения ответных данных, предоставленную стеком протоколов, включенным в операционную систему, и проверяют факт приема данных.
На этапе S65 определяют, были ли приняты в результате выполнения этапа S64 данные приема. Если принимают решение "НЕТ", управление передают на этап S67, количество передач инкрементируют и управление возвращают на этап S61. Если на этапе S65, с другой стороны, принимают решение "ДА", существует высокая вероятность того, что с принтера был принят ответ, соответствующий переданному запросу. Таким образом, если на этапе S65 принимают решение "ДА", то определяют, что был принят ответ на запрос. На этапе S66 создают данные приема как информацию, подлежащую доставке логике доступа 20, являющейся источником запроса на передачу. Например, эта информация включает в себя принятые данные ответа и адрес принтера, передавшего эти данные ответа.
Далее будет описана обработка регистрации адреса стороны, осуществляющей связь, с Фиг.6B. Этой обработкой является обработка, выполняемая в результате вызова, на этапе S30 с Фиг.4A, функции соотнесения блока разрешения имен 301 транспортного блока 30 имя - адрес блоком логики доступа 20. Набор, состоящий из FQDN принтера и его адреса, подают на ввод обработки с Фиг.6B для регистрации адреса стороны, осуществляющей связь. Это FQDN и адрес соотносят и сохраняют на этапе S71. FQDN и адрес, сохраненные в блоке хранения 304, проверяют как кеш адреса. Следовательно, желательно удалить запись (пару, состоящую из FQDN и адреса) из кеша, для которой истек фиксированный период времени хранения без обращений. Это необходимо, поскольку существует возможность обновления адреса и поскольку емкость хранения ограничена. Далее, также и в том случае, если на кешированный адрес передали запрос и ответ не получен, предпочтительно удаление этой записи. Зарегистрированный адрес представляет собой адрес адресата передачи запроса, для которого был возвращен нормальный ответ. Дополнительно, он может, например, являться адресом источника, передавшего нормальный ответ.
Как достоинство вышеприведенной процедуры имя (FQDN) адресата передачи и идентификационная информация (ID запроса), добавленные к пакету, соотносят, таким образом, позволяя идентифицировать принятый ответ как ответ, соответствующий переданному запросу. В результате можно реализовать обработку фильтрации для отброса ответов, иных, чем идентифицированный ответ.
Дополнительно, одновременно можно получать адреса IPv4 и IPv6, и становится возможным уменьшить количество раз, которое выполняют разрешение имени, и уменьшить требуемое время.
Далее, кешируя адрес, для которого удалась связь, соотнесенный с именем (FQDN), количество раз, которое выполняется пакетная передача, можно уменьшить, и даже в том случае, когда на IPv6 сервере DNS зарегистрировано множество адресов. В результате уменьшается объем передаваемых данных.
Несмотря на то что этот вариант осуществления изобретения был описан на примере случая, в котором драйвер принтера передает данные печати, а именно данные запроса, на принтер, можно применять изобретение к передаче данных вообще. То есть изобретение, включающее в себя данный вариант осуществления, можно применить к другой программе приложению или системной программе, а не к драйверу принтера 10. В этом случае логика доступа 20 и транспортный блок 30 будут функционировать аналогичным этому варианту осуществления изобретения образом по отношению к иной программе приложению или системной программе.
Далее, этот вариант осуществления изобретения был описан в форме, в которой логика доступа 20 и транспортный блок 30 содержатся в драйвере принтера. Однако логику доступа 20 и транспортный блок 30 можно разместить вне драйвера принтера и можно вызывать при помощи подходящих интерфейсов, таких как интерфейс вызова функций, при помощи логики драйвера 40. Если применяют такую компоновку, логику доступа 20 и транспортный блок 30 можно использовать, описав интерфейс с логики доступа 20 и транспортным блоком 30 в желаемой программе.
Далее, ID, содержащийся в пакете запроса, а именно данные передачи, представляют собой циклически генерируемый код. Однако достаточным будет любой код, обеспечивающий уникальную идентификацию пакета, такой как точка во времени или комбинация точки во времени и адреса источника передачи.
Далее, в данном варианте осуществления изобретения тот факт, что пригодность ответа определяют, в случае когда данные запроса обладают ID запроса, идентичным тому, с которым сохранили данные ответа, используя в качестве идентификационной информации только ID. Однако можно сравнивать содержимое данных. Например, поля, обладающие значениями, общими для соответствующих запроса и ответа, такие как команды, показанные на Фиг.7A и 7B, можно сравнить и, в том случае если сравниваемые поля совпадают, можно определить ответ как авторизованный. То есть в этом случае ответ определяют как авторизованный ответ, используя в качестве идентификационной информации общие поля запроса и ответа, дополнительно к ID.
Настоящее изобретение можно применить к системе, состоящей из множества устройств (например, основной компьютер, интерфейс, считыватель, принтер и тому подобное) или к устройству, включающему в себя одно устройство (например, копир или факсимильный аппарат и тому подобное).
Этапы обработки в настоящем изобретении можно также реализовать путем исполнения программного обеспечения (программы) на устройстве обработки (CPU или процессоре), таком как персональный компьютер, которое было получено через сеть или различные носители хранения.
Другие варианты осуществления
Также аспекты настоящего изобретения можно реализовать компьютером системы или устройства (или устройств, таких как CPU или MPU), которое считывает и выполняет программу, записанную на запоминающем устройстве, для выполнения функций вышеописанного(ых) варианта(ов) осуществления изобретения. Для этой цели компьютеру предоставляют программу, например, посредством сети или с носителей записи различных типов, выступающих в роли запоминающего устройства (например, считываемого компьютером носителя).
Несмотря на то что настоящее изобретение было описано со ссылкой на примерные варианты осуществления, необходимо понимать, что изобретение не ограничено описанными примерными вариантами осуществления. Область действия приложенной формулы изобретения должна определяться исходя из широчайшей интерпретации, так чтобы охватить все такие модификации и эквивалентные структуры и функции.
Данная заявка включает в себя преимущества заявки на патент Японии номер 2009-117049, от 13 мая 2009 г., каковая полностью включена в данный документ настоящей ссылкой.