Простой компонент позволяющий строить структуру лоакльной сети в виде дерева.

Эта книга является превосходным учебным пособием, дающим наиболее полное и системное понимание основополагающих механизмов Delphi. Цель книги — помочь программистам, начинающим работать с Delphi, сделать первый шаг в ее изучении так, чтобы не возвращаться к пройденному материалу в дальнейшем для углубления знаний. В то же время книга будет интересна и опытным программистам, благодаря своему обобщенному изложению.
Основная часть материала описывает фундаментальные основы Delphi, структуру компонентов и правила их использования. Подробно рассмотрено обьектно-ориентированное программирование в Delphi. Описываются технологии взаимодействия приложений с операционной системой.
Книгу отличает глубокий, системный подход и, в то же время, доступное изложение материала. Используется большое количество наглядных примеров. Лучший выбор для всех, кто хочет получить серьезные знания и грамотно работать с Delphi.

Язык C++ является в настоящее время одним из самых распространенных языков программировании, но одновременно и одним из самых трудных для изучения. Книга «C++: учебный курс» поможет быстро, эффективно и с наименьшими затратами освоить все основные приемы создания приложений на C++. Для изучения всех возможностей языка требуются объемные руководства и справочники, но эта книга даст вам «стартовый толчок», поможет понять структуру языка, принципы обьектно-ориентированного программирования, методику проектирования и создания приложений. Учебный материал, содержащийся в 26-ти уроках, основан на практических примерах и сопровождается исходным кодом программ. Для его освоения не требуется никакой предварительной подготовки. Книга может быть использована в качестве учебного пособия для студентов, изучающих язык C++.

PHP-Fusion 6.01.3 - Cистема управления контентом (CMS), написанная на PHP. Использует базу данных mySQL, где хранит все содержимое веб-сайта.
PHP-Fusion предоставляет простую и наглядную систему администрирования и при этом обладает полным набором функций, необходимых любой CMS.

php-Fusion - это отличный инструмент вебмастера, позволяющий создавать на его базе достаточно сложные порталы.

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

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

Эта книга является одним из первых в России специализированным изданием, написанным отечественными авторами, которое посвящено подробному анализу (без)опасности сети Internet. В книге предлагаются и самым подробным образом описываются механизмы реализации основных видов удаленных атак как на протоколы TCP/IP и инфраструктуру Сети, так и на телекоммуникационные службы предоставления удаленного сервиса в Internet. Особое внимание авторы уделили вопросу обеспечения информационной безопасности в сети Internet. Для этого в простой и доступной для читателей форме были рассмотрены основные способы и методы защиты от удаленных атак в Internet. Для сетевых администраторов и пользователей Internet, разработчиков систем защит, системных сетевых программистов, студентов и аспирантов ВУЗов, а также для всех интересующихся вопросами нарушения и обеспечения информационной безопасности компьютерных сетей.

В книге, написанной создателем языка C++ Биерном Страуструпом, представлено описание процесса проектирования и разработки языка программирования C++. Здесь изложены цели, принципы и практические ограничения, наложившие отпечаток на структуру и облик C++, обсужден дизайн недавно добавленных в язык средств: шаблонов, исключений, идентификации типа во время исполнения и пространств имен. Автор анализирует решения, принятые в ходе работы над языком, и демонстрирует, как правильно применять "реальный объектно-ориентированный язык программирования". Книга удобно организована, поучительна, написана с юмором. Описание ключевых идей даст начинающему пользователю ту основу, на которой позже он выстроит свое понимание всех деталей языка. Опытный программист найдет здесь обсуждение принципиальных вопросов проектирования, что позволит ему лучше понять язык, с которым он работает.

Данная справка входит в "Серию русских справок по C++Builder" и является ее неотъемлемой составляющей. По сравнению с предыдущими версиями 5.1 (ее демо-версия прилагалась к книге Архангельского А.Я "Программирование в C++Builder 5") и 5.2 справка существенно переработана и дополнена.
Справка не является переводом англоязычной справки, встроенной в среду C++Builder 6, и не повторяет ее структуру и темы. Она в значительной степени составлена на основе материалов книги Архангельского А.Я. "Программирование в C++Builder 6" и готовящейся к выпуску книги "C++Builder 6. Справочное пособие", но содержит больше справочных материалов.

Чтобы упростить ориентирование во все более разрастающемся Интернете, была разработана система DNS (Domain Name System - система именования доменов сети). Дело в том, что каждому компьютеру или компьютерной сети, подключенной к Интернету, назначается уникальная последовательность цифр, называемая IP-адресом.

IP-адрес состоит из четырех чисел, от 0 до 255 каждое, например 198.105.232.001. Зная IP-адрес, пользователь одного компьютера с легкостью находит другой компьютер в Интернете, и может к нему подключиться, если у него есть на это соответствующие права. Все просто, когда вам нужно получать доступ к одному-двум компьютерам, но если их количество переваливает за десяток или даже за сотню, а, тем более, если вам необходимо сообщать определенный IP-адрес многим людям, ситуация становится поистине кошмарной.

Избавиться от подобных проблем помогает система имен DNS. Она позволяет заменять цифровые IP-адреса на благозвучные буквенные, например: «microsoft.com» или «yandex.ru». Как же работает DNS? Все Интернет-пространство можно разделить на несколько групп, называемых «доменными зонами». Эти зоны называются доменами первого уровня. Разделение по зонам может проводиться как по географическому, так и по тематическому признаку. Географическая доменная зона определяет расположение компьютера в том или ином государстве. Вот несколько примеров географических доменов первого уровня: ru - Россия, fr - Франция, uk - Великобритания, jp - Япония, su - бывший Советский Союз. Тематические доменные зоны группируют компьютеры по информации, содержащейся на них, либо по типу организаций, ими владеющих, вне зависимости от их географического расположения.

Два компьютера, зарегистрированные в одной тематической доменной зоне, могут находиться в противоположных концах земного шара. Вот примеры тематических доменных зон: com - коммерческое предприятие, net - что-то связанное с сетевыми технологиями, edu - образовательное учреждение, info - информационный проект, gov - государственное учреждение, biz - бизнес-проект, mil - военная организация. Несмотря на обилие доменных зон, далеко не все из них пользуются большой популярностью. Основная часть компьютеров в Интернете зарегистрирована в доменных зонах com и net. Некоторые доменные зоны используются и вовсе не по прямому назначению. Например, островное государство Тувалу стало обладателем географической доменной зоны tv, которую сейчас облюбовали организации, так или иначе связанные с телевидением: телеканалы, производители бытовой техники, киноделы, рекламщики и прочие...

Каждая доменная зона делится на поддомены, или домены второго уровня, и каждому из этих поддоменов присваивается свое имя, например совпадающее с названием организации, владеющей доменом. Это имя приписывается к имени домена верхнего уровня слева, в виде суффикса, и отделяется точкой. Например, в имени microsoft.com строка com означает доменную зону, а суффикс microsoft - имя домена второго уровня. Как нетрудно догадаться, по этому адресу находится сеть, принадлежащая корпорации Microsoft. Однако сеть корпорации Microsoft весьма велика, поэтому каждый домен второго уровня, в свою очередь, может делиться еще на несколько подподдоменов, или доменов третьего уровня. Это записывается так - mail.microsoft.com. В этом примере mail - это суффикс домена третьего уровня. Такое деление может продолжаться до бесконечности, но обычно ограничивается доменами третьего-четвертого уровня.

Общее руководство и контроль над доменными зонами, осуществляет организация ICANN (The Internet Corporation for Assigned Names and Number - Интернет-ассоциация по выдаче имен и чисел). Она передает полномочия на выдачу адресов в той или иной доменной зоне другим организациям и следит за соблюдением основных правил. Организации, уполномоченные выдавать доменные адреса в той или иной доменной зоне, торгуют доменными адресами второго уровня. То есть, если кто-то хочет, чтобы у его компьютера в Интернет был адрес vasya-pupkin.com, он должен обратиться к организации, выдающей доменные имена в зоне com. Затем попросить зарегистрировать в ней домен второго уровня vasya-pupkin, предоставить IP-адрес своего компьютера в Сети и, разумеется, уплатить некоторую сумму денег. В результате, компьютер Васи в Интернете можно будет отыскать не только по малопонятному набору цифр IP-адреса, но и по звучному текстовому адресу.

При желании, одному IP-адресу можно сопоставить даже несколько доменных имен, например vasya-pupkin.com и vasiliy.ru. Адреса в Российской доменной зоне выдает организации РосНИИРОС, Российский НИИ развития общественных сетей.

Современный Интернет представляет собой сложнейшую систему из тысяч компьютерных сетей, объединенных между собой. Состоит эта система из двух основных элементов: узлов сети Интернет и соединяющих их информационных магистралей. Узлом Интернета называют любое устройство, имеющее свой IP-адрес и подключенное к Сети. Несмотря на кажущуюся мешанину межкомпыотерных соединений и отсутствие централизованного руководства, Интернет имеет определенную иерархическую структуру.

В самом низу иерархии находится многочисленная армия конечных пользователей. Часто не имеющие даже постоянного IP-адреса подключаются к Интернету по низкоскоростным каналам. Тем не менее, пользователи являются одними из основных потребителей услуг Сети и главными «спонсорами» коммерческой части Интернета. Причем на одного «физического» пользователя, т. е. реального человека, пользующегося услугами Сети, может приходиться несколько пользователей «логических», т. е. различных подключений к Интернету.

Так, кроме компьютера, возможность подключения к Интернету может иметь мобильный телефон, карманный компьютер, бытовая техника, автомобиль и даже кондиционер. Конечные пользователи подключаются к компьютерам Интернет-провайдера, или, как их еще называют, ISP (Internet Service Provider - провайдер Интернет). ISP - это организация, основная деятельность которой связана с предоставлением услуг Интернета пользователям.

У провайдера есть своя компьютерная сеть, размеры которой могут варьироваться от сотен десятков узлов в нескольких городах до многих тысяч, раскиданных по целому континенту. Эта сеть называется магистральной сетью, или бэкбоном (от слова backbone - стержень, магистраль). Сети отдельных провайдеров соединяются между собой и другими сетями. Среди ISP есть «монстры», которые обеспечивают соединение между собой сетей различных стран и континентов, являясь своего рода «провайдерами для провайдеров». Весь этот конгломерат компьютерных сетей и образует то, что называется Интернетом.

Особняком стоят DNS-серверы - компьютеры, отвечающие за функционирование системы DNS. Для подключения конечных пользователей к ISP служат так называемые «точки доступа» - компьютеры или специальные устройства, содержащие оборудование для подключения «извне».

Подключившись к точке доступа провайдера, пользователь становится частью магистральной сети провайдера и, соответственно, получает доступ к ее ресурсам, а также к ресурсам сетей, соединенных с бэкбоном провайдера, т. е. ко всему Интернету. Кроме конечных пользователей, к сети провайдеров подключаются различного рода серверы, или «хосты» (от слова host - хозяин). Это узлы сети, на которых работает программное обеспечение, обеспечивающее практически все услуги, предоставляемые сетью Интернет.

В данной статье приведены общие сведения об организации работы системы 1С:Предприятие с распределенной информационной базой (ИБ). Также описаны внутренние особенности организации механизма работы с распределенными данными для того, чтобы специалисты, осуществляющие конфигурирование и администрирование распределенных систем могли лучшее понимать выполняемые системой действия. Данная информация может также быть использована для оценки дополнительных затрат ресурсов системы, расходуемых на поддержание распределенной информационной базы.

Так как средства системы 1С:Предприятие для работы с распределенными информационными базами поставляются отдельно, сначала кратко остановимся на назначении и основных принципах организации работы системы 1С:Предприятие с территориально удаленными подразделениями.



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

Для решения подобных задач предназначена компонента "Управление распределенными ИБ". С помощью указанной компоненты можно организовать двухуровневую структуру информационных баз (ИБ) системы 1С:Предприятие, состоящую из одной центральной и нескольких периферийных информационных баз, работающих с единой конфигурацией. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.

Содержимое информационных баз синхронизируется путем переноса измененных объектов данных между каждой из периферийных и центральной ИБ. Для переноса данных используются так называемые файлы переноса данных. Перенос изменений выполняется только между центральной и периферийными ИБ. Перенос данных непосредственно между периферийными ИБ невозможен. Поэтому изменения данных, произведенные в одном из периферийных узлов распределенной ИБ попадают в другие периферийные узлы только через центральную ИБ.

В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.

В некоторых случаях может возникнуть необходимость в том, чтобы объекты того или иного типа никогда не попадали в те или иные узлы распределенной ИБ или никогда не покидали места своего создания. Для обеспечения такой возможности предназначен механизм настройки параметров миграции объектов. С его помощью можно ограничить распространение изменений объектов того или иного вида. Кроме того, в версии 7.7 системы 1С:Предприятие можно создавать периферийные ИБ, которые будут принимать информацию о измененных объектах из центральной ИБ, но не будут передавать изменения, сделанные в них самих.

Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.

Однако, для того, чтобы документы, элементы справочников и другие объекты, созданные в разных узлах распределенной ИБ, имели заведомо непересекающиеся пространства номеров, кодов и т. п., может потребоваться внести в конфигурацию некоторые изменения. Также изменения в конфигурации должны вноситься при необходимости обеспечить специальные ограничения работы пользователей на периферийных информационных базах.

Для переноса измененных объектов в распределенной ИБ и для первичного создания периферийной ИБ используется файл переноса данных. Он представляет собой упакованный (сжатый) файл, содержащий объекты информационной базы (все при создании периферийной ИБ или измененные при передаче изменений) в специальном формате. Формат данного файла не предназначен для использования его способами отличными от тех, которые предусмотрены механизмами выгрузки/загрузки и передачи изменений. Файл переноса фактически отражает содержимое объектов информационной базы в формате, не зависящем от формата базы данных. Это позволяет использовать в распределенной информационной системе в различных узлах различные форматы хранения данных, поддерживаемые системой 1С:Предприятие (DBF/CDX и MS SQL Server).



Перенос измененных данных производится "пообъектно". То есть единицей переноса данных является так называемый ведущий объект. С точки зрения работы в распределенной информационной базе в 1С:Предприятии существуют следующие типы ведущих объектов:

константа,

элемент справочника,

документ,

календарь,

счет бухгалтерского учета,

типовая операция.

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

Регистрация изменений объектов производится автоматически при любом изменении объекта, независимо от того каким способом это изменение производилось (интерактивно или из встроенного языка). Кроме того в версии 7.7 системы 1С:Предприятие для таких объектов как элементы справочников и документы появилась возможность управления регистрацией изменений. Для этого у соответствующих объектов метаданных введен признак "Автоматическая регистрация изменений". Если этот признак установлен (значение по умолчанию), то автоматическая регистрация производится, а если признак сброшен, то регистрация не производится и изменения объектов в распределенной ИБ не распространяются. Но и в данном случае, при выполнении записи изменений объектов из встроенного языка можно управлять регистрацией изменений с помощью метода встроенного языка РегистрацияИзменений().

Регистрация изменений ведущих объектов производится в специальной служебной таблице. При этом фиксируются следующие данные об изменении объекта:

Сам ведущий объект;

Идентификатор той ИБ, в которую должно быть передано изменение;

Идентификатор ИБ, в которую должно быть передано изменение, служит для отслеживания переноса данных в каждую из ИБ, с которой данная ИБ обменивается данными. Таким образом, при изменении какого-либо объекта в центральной ИБ в таблицу будет помещено по одной записи для каждой из зарегистрированных периферийных информационных баз. Если же изменение объекта происходит в периферийной ИБ, то в таблицу будет занесена только одна запись, соответствующая центральной ИБ, так как каждая из периферийных ИБ непосредственно взаимодействует только с центральной.

Заметим, что удаление объекта является частным случаем изменения. Оно также помечается в таблице регистрации изменений и передается при выгрузке.

Выгрузка и загрузка изменений

Каждая выгрузка изменений осуществляется в адрес конкретной ИБ. В файл переноса, создаваемый при выгрузке попадают все объекты, записи об изменениях которых содержатся в таблице регистрации изменений для данной ИБ.

Заметим, что выгружаются не изменения объектов, а сами измененные объекты. То есть, если в документе изменилось значение одного реквизита, то будет передаваться весь документ и он будет полностью перезаписан на той ИБ, в которую переносится. Как уже отмечалось, вместе с документом будут перенесены и сделанные им движения регистров, операция и проводки. Если изменяется любой реквизит справочника, то передается полностью весь элемент. При этом история периодических реквизитов передается целиком. Последнее означает, что изменения сделанные в истории периодического реквизита элемента на в двух ИБ не будут сливаться вместе.

В процессе выгрузки в таблице регистрации изменений отмечается выгрузка изменений объектов.

При загрузке файла переноса данных помимо загрузки измененных данных выполняется так называемый прием подтверждений.

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

Причем выгрузка измененного объекта будет производиться до тех пор, пока не будет получено подтверждение, о доставке изменения. Это значит, что если выполнять перенос все время в одном направлении и не выполнять обратного переноса то объем файла переноса данных будет все время расти, так как каждый раз будут передаваться все объекты, измененные после последнего полученного подтверждения.

При загрузке изменений объектов из периферийной ИБ в центральную, в таблицу регистрации изменений (если, конечно, параметры миграции настроены соответствующим образом) заносятся записи, указывающие, что загруженные из периферийной ИБ изменения объектов должны быть переданы в другие периферийные ИБ.

Изменения конфигурации

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

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

После записи измененной конфигурации в распределенной ИБ складывается такая ситуация, что центральная и периферийные ИБ работают фактически с разными конфигурациями. В таком состоянии созданные на периферийной ИБ файлы переноса данных не могут быть загружены на центральной ИБ по той причине, что в условиях различных конфигураций содержащаяся в файле информация не может быть правильно интерпретирована. Обмен будет восстановлен только после того, как в периферийную ИБ будет загружена измененная конфигурация с центральной ИБ. То есть после изменения конфигурации требуется выполнить перенос из центральной ИБ в каждую из периферийных, а уже затем выполнять перенос из периферийных ИБ в центр.

Перенос измененной конфигурации в периферийные ИБ осуществляется тем же способом, что и перенос измененных объектов данных. В процессе очередной выгрузки из центральной ИБ, в файл переноса данных целиком включается измененная конфигурация, если, конечно, в таблице регистрации изменений содержится запись о том, что измененную конфигурацию следует передать в соответствующую периферийную ИБ. Выгрузка конфигурации также будет производиться до получения извещения о приеме измененной конфигурации.

Заметим, что конфигурация считается измененной при любых изменениях метаданных, форм, модулей, таблиц конфигурации, наборов прав, пользовательских интерфейсов, описаний. В состав конфигурации не входит список пользователей, а также внешние по отношению к файлу конфигурации (1CV7.MD) файлы (внешние отчеты, отдельно записанные таблицы и тексты). И эти внешние файлы не переносятся механизмом управления распределенной ИБ. Поэтому при конфигурировании распределенной системы не рекомендуется использовать в конфигурации находящиеся в отдельных файлах модули, таблицы и отчеты.

Для изменения уже работающей конфигурации можно рекомендовать использовать механизм загрузки измененной конфигурации. Он позволяет специалисту скопировать конфигурацию, выполнить в ней все необходимые изменения, отладить внесенные изменения (этот процесс может занять и несколько дней), а затем загрузить измененную конфигурацию в центральную ИБ, после чего изменения будут распространены на все периферийные ИБ с очередной передачей изменений. Такая последовательность позволит избежать многократной передачи измененной конфигурации в периферийные ИБ в процессе ее модернизации.

При загрузке файла переноса данных на периферийной ИБ, этап загрузки измененной конфигурации (если, конечно, она содержится в файле переноса данных) предшествует этапу загрузки измененных объектов данных. В случае неудачного завершения загрузки конфигурации, загрузка объектов данных производиться не будет и информационная база останется в том же состоянии, что и была до начала загрузки.

Продолжение статьи


[pagebreak]

Загрузка измененной конфигурации может завершиться неудачей, если измененная конфигурация не соответствует существующим данным. Например, было уменьшено число уровней справочника, а новое число уровней оказывается меньшим, чем фактически содержащееся в справочнике или в других подобных случаях. Если такое произошло, то следует привести данные в соответствие с новой конфигурацией или изменить конфигурацию в центральной ИБ и заново произвести выгрузку, чтобы ликвидировать возникшее противоречие.

Коллизии

При работе в реальных распределенных ИБ один и тот же объект может изменяться одновременно в различных узлах распределенной ИБ. И при переносе измененных объектов из одной ИБ в другую может случиться так, что в какую-либо ИБ будет загружаться объект, зарегистрированный в самой этой ИБ как измененный. Такая ситуация носит название коллизии. Приведем описание действий системы в наиболее типовых вариантах коллизий.

Один и тот же объект изменен более чем в одной ИБ.

Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются.

Объект, измененный в одной ИБ, удален в другой.

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

Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ.

Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.

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

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

При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.

Таким образом, управление распределенной информационной базой имеет определенную стратегию автоматического разрешения любых коллизий с описанными приоритетами. Однако, в реальных условиях рекомендуется средствами конфигурации определить возможные действия пользователей на различных узлах таким образом, чтобы исключить или минимизировать вероятность возникновения коллизий. Основным путем является определения средствами конфигурации "ответственного" узла за каждый ведущий объект в распределенной ИБ и ограничение всем остальным возможности его редактирования и удаления. Определение "ответственных" должно происходить исходя из логики работы предприятия. Очевидно, что многие виды объектов можно разрешить изменять только в центральной ИБ (например, список складов). Для многих объектов можно рекомендовать средствами встроенного языка установить возможность изменения только на той ИБ, на которой они созданы, например для документов.

Параметры миграции

С помощью настройки параметров миграции можно ограничивать области распространения изменений объектов. Настройка параметров миграции происходит по видам "ведущих" объектов. То есть для каждого вида "ведущих" объектов можно определить конкретную настройку параметров миграции. В настройке параметров миграции объектов ведущую роль играет выбор того или иного варианта области распространения изменений объектов данного вида. Существуют три варианта настройки области распространения:

Все информационные базы. Данный вариант настройки используется по умолчанию для всех объектов. В этом случае любые изменения объектов данного типа будут распространяться по всем узлам распределенной ИБ. Этот вариант обеспечивает полную синхронизацию объектов данного вида во всей распределенной ИБ. Очевидно, что этот вариант наиболее прост для конфигурирования.

Место создания. Данный вариант настройки также является довольно простым. В этом случае изменения объекта не передаются в другие ИБ. При такой настройке параметров миграции, объект данного вида никогда не "покидает" места своего создания и не появляется в других ИБ. Однако при выборе данного варианта следует учитывать возможные ссылки на объекты данного вида из объектов других видов, имеющих другие параметры миграции. Например, если установить такой вариант для справочника, и в документах, которые участвуют в обмене, будет содержаться реквизит типа справочник данного вида, то при переносе документа получится неразрешенная ссылка.

Место создания и центр. При таком варианте настройки области распространения объектов существенную роль играет понятие места создания объекта. Местом создания объекта считается ИБ, в которой был создан конкретный объект. Естественно, что различные объекты одного вида могут быть созданы в различных ИБ. Однако место создания объекта может быть определено не для всех видов "ведущих" объектов. Для таких объектов как константы, календари или корректные проводки место создания не определено. Поэтому для этих видов объектов вариант настройки "Место создания и центр" не может быть установлен.

В случае выбора такого варианта области распространения, объекты данного вида помимо места их создания попадают еще и на центральную ИБ. То есть, в случае, если для некоторого вида объектов установлена область распространения "Место создания и центр", то для объектов этого вида, созданных на периферийной ИБ, их изменения будут передаваться между местом их создания и центральной ИБ. Для объектов того же вида, созданных на центральной ИБ, изменения не будут передаваться никуда. С помощью такого варианта области распространения можно добиться такого эффекта, что все объекты того или иного вида будут "собираться" на центральной ИБ, а на любой из периферийных ИБ будут находиться только те объекты, для которых она является местом создания.

В случае выбора области распространения "Место создания и центр", для вида объекта можно задать перечень периферийных узлов распределенной ИБ, которые дополнительно включаются в область распространения всех объектов данного вида. Этот перечень задается как список кодов периферийных ИБ, разделенный запятыми. При задании кодов ИБ допускается использование символов-заменителей '*'. Символ-заменитель должен завершать последовательность символов, образующих код одной или нескольких периферийных ИБ. Таким образом, "A*" представляет собой обозначение всех периферийных ИБ, коды которых начинаются символом 'А'. Последовательность "A*B" является ошибочной, так как символ '*' не завершает последовательность символов, представляющих код периферийной ИБ.

Кроме того, как отмечалось выше, дополнительной возможностью управлять распространением изменений объектов в версии 7.7 системы 1С:Предприятие является особый вид периферийных ИБ, которые получают изменения из центральной ИБ, а сами информацию о сделанных в них изменениях не передают. Для создания периферийной ИБ такого рода, надо при ее инициализации указать признак "Только получатель".

Отдельно стоит рассмотреть случай, когда параметры миграции объектов изменяются в процессе изменения конфигурации уже работающей системы. Изменения параметров миграции для каждого из объектов производится независимо от других. То есть, Конфигуратор не отслеживает ссылки между объектами при настройке параметров миграции. Таким образом, при определенных вариантах настройки параметров миграции у некоторых объектов могут появиться ссылки, указывающие "никуда". Ответственность за сохранение ссылочной целостности в распределенных ИБ возлагается на лицо, занимающееся конфигурированием системы. Общим правилом настройки параметров миграции является определение области миграции для конкретного вида объектов равной более широкой, чем область миграции ссылающихся на него объектов. Например, для справочника область миграции должна быть определена не уже, чем области миграции документов и справочников, в которых есть реквизиты типа "справочник" данного вида. Если, например, измерение регистра имеет тип "справочник" данного вида, то область миграции справочника должна покрывать области миграции всех документов, которые могут записать движения данного регистра.

При изменении параметров миграции того или иного объекта система старается привести имеющиеся данные в соответствие с новыми параметрами. Общим принципом здесь является то, что при изменении параметров миграции объекты никогда ни в каком узле распределенной ИБ не удаляются. Даже в том случае, если в соответствии с вновь установленными параметрами миграции их там быть не должно. Изменения производятся лишь в таблице регистрации изменений. Рассмотрим случаи изменения параметров миграции объектов подробнее.

Наиболее простой случай - это смена любого из вариантов области распространения на вариант "Место создания". В этом случае из таблицы регистрации изменений удаляются все записи по данному виду объектов. То есть все изменения объектов, еще не переданные в другие ИБ, не будут переданы. При этом, все объекты для которых данная ИБ не является местом создания, не будут удалены. Просто их изменения (как и изменения других объектов данного вида) не будут больше передаваться в другие ИБ.

Следующий случай - это смена области распространения "Место создания" на варианты "Все информационные базы" или "Место создания и центр". В этом случае в таблицу регистрации изменений заносятся записи для передачи всех объектов, для которых текущая ИБ является местом создания во все ИБ, в которые должны передаваться изменения в соответствии с вновь заданной настройкой. В случае, если такая смена производится для объектов, для которых место создания не определено (константы, календари, корректные проводки), то записи в таблицу регистрации изменений будут произведены только в центральной ИБ. Этими двумя вариантами и ограничиваются возможные случаи изменения параметров миграции для такого рода объектов. Все остальные случаи возможны только для тех объектов, для которых место создания можно определить.

При изменении области распространения объектов с "Место создания и центр" на "Все информационные базы", какие-либо действия предпринимаются только в центральной ИБ. В этом случае определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. После этого производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи состояния объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.

Последний и самый сложный случай - это изменение области распространения объектов с "Все информационные базы" на "Место создания и центр" или изменение списка дополнительных ИБ в варианте "Место создания и центр". Действия, производимые в данном случае различаются в зависимости от того, производятся они в центральной ИБ или в периферийной. В центральной ИБ для каждой из периферийных ИБ, не попавших в новый перечень дополнительно включаемых в область распространения, выполняется удаление из таблицы регистрации изменений записей соответствующих данному виду объектов, но только для тех объектов, для которых эта периферийная ИБ не является местом создания. Затем определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. Естественно, что в случае, если предыдущим вариантом настройки области распространения было "Все информационные базы", то этот список окажется пустым. Затем, как и в предыдущем случае, производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.

Проблемы конфигурирования и администрирования

При разработке конфигурации для распределенной ИБ проявляется ряд объективно существующих проблем, которые решаются как средствами конфигурации, так и административными решениями.

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

Более сложной проблемой является ситуация, когда возникает необходимость использования некоторого нового объекта в двух и более узлах одновременно, до осуществления передачи данных. Например, новый товар должен быть введен и на центральной ИБ и на периферийной. Важно понимать, что созданный ведущий объект системы 1С:Предприятие обладает некоторой сущностью - внутренним идентификатором, который уникален во всей распределенной системе. То есть один и тот же объект не может быть введен в двух узлах. Даже при полном соответствии кодов, номеров и всех данных это будут два разных объекта. Такой принцип необходим для четкой работы системы со всех точек зрения.

Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.

Поэтому, на наш взгляд, решение проблемы должно лежать в области администрирования системы. Технология работы пользователей должна быть построена таким образом, чтобы ввод объекта производился на одном узле.

В отдельных случаях может использоваться следующее решение. В справочник заранее вносится некоторое количество новых элементов со специальными кодами или в специальную группу. При появлении необходимости ввода нового товара реально не вводится новый элемент, а изменяется один этих элементов. При этом административными силами должно быть обеспечено идентичное изменение одного и того же "зарезервированного" объекта в тех узлах распределенной ИБ, в которой он должен быть использован до обмена данными. При обмене данными сами реквизиты элемента будут системой синхронизированы, а ссылки в других объектах, разумеется будут идентичными, так как использовался один и тот же объект.

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

Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".

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

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

Внешнюю обработку можно создать в конфигураторе:



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



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



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

Формат PDF был разработан фирмой Adobe Systems, чтобы решить проблему единства отображения и обработки полиграфической продукции в различных информационных средах (его кроссплатформенность) и довольно успешно справляется с этой задачей и по сегодняшний день. Однако со временем у этого формата появилось и иное предназначение. Универсальность этого формата спровоцировала рост его популярности, а, следовательно, увеличилось и количество публикаций, доступных в этом формате в электронном виде в Интернете.

Изначально файлы формата PDF в сознании многих людей ассоциировались именно с качественным уникальным контентом, т. к. с его помощью часто публиковались и публикуются различные отчёты, доклады, статьи, руководства и другая полезная информация. Конечно, было бы глупо упускать такой источник полезной информации. Со временем все популярные поисковые системы научились индексировать файлы PDF и ранжировать их, что автоматически поставило их наравне с привычными для нас файлами в формате HTML (веб-страницами).

Нам же важно не упустить возможную выгоду и научиться правильно оптимизировать файлы подобного рода для поисковых систем, чтобы обеспечить их лучшую видимость в результатах поиска. Долгое время файлы PDF воспринимались исключительно как файлы-архивы, для открытия которых необходимо было их загружать на компьютер и читать в сторонней программе (Например, в Adobe Reader – программе для просмотра формата PDF). Так было раньше, сейчас же многое меняется: значительно увеличиваются скорости Интернета, появляются встроенные в браузер плагины для чтения формата PDF, позволяющие просматривать файлы сразу же в браузере. Например, уже сегодня в браузере Opera можно читать файлы PDF прямо на сайте онлайн. А это всё прямое свидетельство того, что популярность этого формата в обозримом будущем будет только расти. Это теперь не только универсальный формат для хранения и редактирования полиграфии, но также и способ передачи информации в Интернете (выполняющий функции обычной веб-страницы).

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

Любой веб-мастер и seo-оптимизатор должен понимать, что файл PDF - это такая же страница сайта, как и файл в формате HTML. Как правило, на этот файл ссылаются так, что он является тупиковым для поисковой системы, т. к. в нём почти никогда не содержатся ссылки на другие страницы сайта, а зря. Каждый PDF-файл (как и страница HTML) находится в индексе поисковых систем, следовательно, имеет и свой поисковый вес, передаваемый по ссылкам (вИЦ или PR, если хотите). Я настоятельно рекомендую вам в любом файле PDF, выложенным на сайте, делать ссылки на обычные HTML-страницы сайта и на другие страницы PDF (можно даже продублировать навигацию основного сайта). В данном случае вы будете только в выигрышном положении, т. к. помимо передачи поискового веса по ссылке, посетитель, скачав файл PDF с вашего сайта и ознакомившись с информацией в нём, может к вам вернуться, щёлкнув по ссылке, ведущей на ваш сайт из скачанного документа. К тому же файл PDF редко редактируется, поэтому часто сохраняется в первоначальном виде, а также как файловый архив может стремительно распространяться через различные файловые хостинги, а это, опять же, новые пользователи для вашего сайта (тот редкий случай, когда поисковая оптимизация напрямую влияет на непоисковое продвижение).

ПРОГРАММЫ ДЛЯ РАБОТЫ С ФАЙЛАМИ PDF

Для создания файлов PDF используйте программу Adobe Acrobat, т. к. она имеет целый арсенал средств, которые способны максимально качественно оптимизировать наши файлы. Несмотря на это, можно (но не рекомендуется) использовать и другие программы. Например, для создания файлов PDF вы можете использовать связку программ Adobe Pagemaker и Adobe InDesign или текстовые редакторы наподобие Word из пакета Microsoft Office или Write - из OpenOffice. Когда будете использовать текстовый редактор Word для создания документа формата PDF, то используйте теги H1, H2, H3 и другие подобные для оптимизации текста документа. Вы должны сделать полученный текст базирующимся на языке HTML, чтобы поисковые системы эффективно его индексировали.

Не используйте программы типа Photoshop и Illustrator, т. к. после обработки документа на выходе информация превращается в одно большое изображение, текст на котором не распознать поисковым системам. Однако часто случается и то, что у веб-мастера уже есть большое количество PDF-файлов, полученных от заказчика, или же специфика темы на сайте такая, что по ней есть информация в электронном виде только в этом формате. Если у вас именно такой случай, то не отчаивайтесь. Сейчас активно разрабатываются программы, способные распознавать текст на изображениях, что позволяет модифицировать текст на изображениях в обычный текст, который индексируется поисковыми системами. В России довольно успешно распознаванием текстов занимается компания ABYY. К примеру, вы можете воспользоваться их конвертером Abbyy PDF Transformer. Хочу сразу заметить, что это довольно уникальный продукт, аналогов которому почти нет. В его возможности входит конвертирование текста на картинках PDF в текст, способный индексироваться поисковыми системами.

Несколько слов, я думаю, можно сказать и про программы конвертеры. Если же вы решили, что по каким-то причинам формат PDF на сайте вас не очень устраивает, а контент вашего сайта состоит, в основном, из файлов PDF, то у вас есть возможность переконвертировать эти файлы в формат HTML, используя различные бесплатные и платные PDF конвертеры.

Вот небольшой список таких конвертеров:

* Advanced PDF to HTML
* Comfortable PDF to HTML
* Easy PDF to HTML
* Adobe Acrobat Pro Extended – это конвертер компании Adobe, но известно, что оптимизаторы испытывают сложности с этой программой.

Теперь, я думаю, самое время поделиться с вами секретами оптимизации файла PDF для поисковых систем.

ИЗОБРАЖЕНИЯ

Не используйте слишком много изображений или изображения большого размера. Картинки хоть и улучшают внешний вид, однако также увеличивается размер файла и время его загрузки. Как и на HTML-странице, если вы поставите много изображений (особенно неоптимизированных), то это потребует больше времени для их загрузки в браузер. Но помимо оптимизации размера изображений PDF-документа, необходимо также оптимизировать и подписи (альтернативный текст) к ним. У каждого изображения документа должна быть своя подпись, как к картинкам обычной HTML-страницы.

РАЗМЕР ФАЙЛА

Нужно всегда помнить, что поисковые системы не индексируют файлы, которые слишком много весят. Например, поисковая система "Яндекс" не будет индексировать файлы весом больше, чем 10 Мб, отсюда следует правило, что файл PDF не может быть больше 10 Мб.

Если говорить про оптимальный размер PDF-файла, то многие seo-оптимизаторы считают его величину в пределах 500 - 1000 Кб, т. к. с файлами именно таких размеров происходит меньше всего ошибок, связанных с индексацией файлов.

Для оптимизации размера в программе Adobe Acrobat есть специальная функция: Advanced > PDF Optimizer.

Внимание! При создании PDF-документа в любом редакторе обращайте внимание на версию получаемого файла. Рекомендуемая версия – 1.5 и ниже, т. к. такой файл гарантированно будет читаться всеми программами для просмотра PDF и роботами поисковых систем. Формат PDF позволяет оптимизировать также и копию документа, поэтому по возможности оптимизируйте и её.

ТЕКСТ ФАЙЛА

Старайтесь избегать большого количества текста в одном файле PDF, дробите один файл на несколько файлов, причём, линкуйте их ссылками внутри каждого такого документа (так, как бы вы это делали с обычными HTML-документами).

Оптимизируйте текст файла PDF под конкретные ключевые запросы, а здесь надо уделять внимание таким же показателям, как и на обычной веб-странице (плотность ключевых слов не выше 5% и прочим). Если вы хотите получить хорошо индексируемый и релевантный поисковым запросам контент PDF-документа, вы должны стараться избегать нагромождения страниц в нём. При внутренней оптимизации текста, а именно: заголовков и подзаголовков, ключевых слов и фраз, необходимых для вашего документа, - будьте очень осторожны, чтобы файл не выглядел заспамленным и не вылетел, в итоге, из индекса поисковых систем.

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

Сделайте оглавление (поисковую карту документа), каждый пункт этого оглавления оформите ссылкой (закладкой) внутри PDF документа, для каждой ссылки пропишите ключевые слова в описании ссылки. Этот приём наиболее эффективен для документов, состоящих из нескольких логический частей и с большим количеством страниц – он обеспечивает качественную внутреннюю перелинковку документа, позволяющую эффективно индексировать документ поисковым роботам.

Если вы хотите создать справочник, руководство или другой документ, предполагающий большой объём информации в одном файле, то я рекомендую создавать подобные документы в формате DjVu. Страницы документов (контент) в этом формате не индексируются поисковыми системами. Но если по каким-то причинам у вас не получается уменьшить размер PDF-файлов и разбить их на несколько отдельных файлов, то можно воспользоваться очень удобной функцией в программе Adobe Reader - Optimize for Fast Web View, позволяющей просматривать уже загрузившиеся страницы документа, не дожидаясь его окончательной загрузки. Это удобно для тех пользователей, кто будет просматривать ваш PDF-файл непосредственно на вашем сайте в режиме онлайн.

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ (МЕТАПОЛЯ)

Очень важно заполнить всю дополнительную информацию о вашем файле PDF. Уделите особое внимание таким тегам как: Title (заголовок), Author (автор материала), Subject (тема), Keywords (ключевые слова документа), Descriptions (описание PDF-документа) и Copyright (авторские права). Все эти настройки можно найти в программе Adobe Acrobat в меню File > Document Properties. Метаданные файла PDF имеют схожее происхождение с метатегами файлов HTML, так что уделяйте им особое внимание при оптимизации.

КОДИРОВКА, ШРИФТЫ И РАСПОЛОЖЕНИЕ ФАЙЛА

Несколько слов нужно сказать и про оптимизацию шрифтов. Не забывайте включать в сам файл все необходимые (нестандартные) шрифты. Довольно часто для декоративных целей используются самые разнообразные и редкие полиграфические шрифты, которые могут плохо восприниматься поисковыми системами, поэтому, по возможности, старайтесь пользоваться стандартными шрифтами (Arial, Helvetica, Sans-Serif, Times New Roman и другими), которые хорошо индексируются поисковыми системами. Их плюс в том, что они присутствуют по умолчанию в любой операционной системе, поэтому из документа PDF их можно спокойно исключить, уменьшив тем самым размер файла.

Шрифты, которые не были добавлены в PDF-документ или отсутствуют в операционной системе, будут отображаться тем шрифтом, который имеется (самым близким по значению), что может привести к нежелательным последствиям, а именно к увеличению или уменьшению числа страниц, количества символов в строках, межстрочного интервала и других проблем метрики.

Довольно болезненный параметр для поисковых систем - кодировка файла. Если поисковая система не сумеет определить кодировку вашего PDF файла самостоятельно, то документ вообще не будет проиндексирован, поэтому всегда проверяйте, указана ли она. Желательно использовать самые известные и популярные кодировки.

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

Не давайте вашим документам в формате PDF слишком сложные имена. Упрощайте их. Несколько слов в названии самого файла разделяйте символом "_". Например: imya_documenta.pdf. Также для разделителя можно использовать и символ "-", но я рекомендую использовать первый вариант.

После всех проделанных операций по оптимизации можете выкладывать файл на сайт. Поисковые системы найдут файл, проиндексируют его и начнут выводить в результатах поиска, и если материал интересен, начнётся самораскрутка его среди посетителей - на файл начнут ссылаться, скачивать и публиковать его в других местах (а сам файл будет с ссылками на ваш сайт). Неплохо, не правда ли?

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

http://ru.wikipedia.org/wiki/PDF - общая информация о файле PDF
http://get.adobe.com/reader/ - последняя версия Adobe Reader
http://www.adobe.com/products/acrobat/ - последняя версия Adobe Acrobat
http://www.abbyy.ru/pdftransformer/ - последняя версия Abbyy PDF Transformer
http://www.taurion.ru/acrobat - самоучитель работы в программе Adobe Acrobat

В этом обзоре я постарался ответить на наиболее распространённые вопросы по оптимизации файла PDF, которые задают люди, занимающиеся раскруткой сайтов. Но если у вас появились вопросы или что-то осталось непонятным, то, пожалуйста, сообщайте об этом! Буду рад любым отзывам от вас! Спасибо!

Многие мои друзья и знакомые часто спрашивают меня о том, как устроен мой сайт, сколько у меня таблиц в базе данных, как я храню данные и по каким полям веду поиск. Я, конечно, не выдаю все свои государственные тайны, но всегда понимаю причину таких вопросов и пытаюсь помочь людям построить быструю и надежную базу данных - т.е. тщательно продумать структуру БД таким образом, чтобы при увеличении нагрузки или объема таблиц динамический веб-сайт не превратился в тормозное усмертие.

А ведь многие новички (веб-строители) даже не догадываются о том, что крупные динамические сайты тормозят вовсе не из-за нагрузки скриптов на процессор, а в основном из-за неоптимизированного или дохленького MySQL-сервера. При этом во многом все зависит от того, как устроена ваша база данных.

Итак, начнем ликбез. Сразу всем вопрос: что делает MySQL во время записи в таблицы типа INSERT или UPDATE? Правильно - БЛОКИРУЕТ ТАБЛИЦЫ и пишет в них данные. Скорость записи и поиска может быть достаточно низкой, поэтому статус таблиц запрещает другим процессам считывать из них данные до окончания операции записи или обновления и снятия блокировки. При этом может получиться так, что во время записи единственного поля в длинные таблицы, ваш MySQL-сервер надолго заблокирует доступ к таблице остальным скриптам.

Например, вы создали таблицу новостей такого типа:

ID - номер, первичный ключ
TEMA - тема новости
MESS - сообщение, сама новость
VIEWS - количество просмотров

При каждом обращении к новостям, скрипт будет выводить саму новость, а потом увеличивать поле VIEWS запросом UPDATE table 'NEWS' set VIEWS=VIEWS+1 where id=ID. При этом количество апдейтов будет довольно высоким. При высокой посещаемости веб-ресурса или при "нападении" на сайт поискового робота (эти ребята страдают многопоточностью и могут запросто повесить ваш сайт своими запросами) несколько одновременных процессов станут пытаться сделать UPDATE и SELECT. При каждом UPDATE таблица будет блокироваться (на это уходит время) и все остальные процессы будут ждать завершения операции. А если таблица достаточно большая? Например, несколько тысяч записей. Ежу понятно, что построится очередь из нескольких десятков скриптов, ожидающих ответа MySQL-сервера. Каждый будет жрать память и держать остальные процессы. В итоге все у вас зависнет и переглючит. Выход: делать вместо одной таблицы несколько. Советую разделять поля по типу их использования. Одну таблицу - только для вывода и редких обновлений или вставок. Другую - для частых обновлений, но редкого вывода. Например, значения счетчика обращений держать отдельно в таблицу вида:

ID - номер, первичный ключ
VIEWS - количество просмотров

Сами новости лучше держать в другой таблице, где нет поля VIEWS. При этом таблица с новостями будет тяжелой (много текста, полей, индексов), а таблица COUNT (счетчик) будет очень легкой и быстрой. Таблица NEWS будет кешироваться и выводиться очень быстро при любых объемах, а таблица COUNT будет быстро обновляться из-за того, что она очень легкая (всего два целочисленных поля). Разделение данных по нескольким таблицам существенно ускоряет работу MySQL-сервера. Гораздо быстрее работают несколько мелких запросов по каждой таблице, чем один длинный запрос по одной или нескольким таблицам. Имейте это в виду, чтобы спать спокойно.

Дальше - круче. Чтобы не блокировать лишний раз свои таблицы используйте при вставках директиву DELAYED. Пример: INSERT DELAYED into STAT (ID,IP,UTIME) values (null,$ip,NOW()). Он позволяет серверу ответвлять поток в режиме ожидания, а саму вставку производить тогда, когда сервер освободится от других запросов или поступит следующий аналогичный INSERT DELAYED. Обычно отложенный метод подходит для любых операций с кумулятивными таблицами (когда в основном идут INSERTы, а данные копятся, а не модифицируются), при которых не особо важно когда именно подействуют изменения - мгновенно или через несколько секунд, минут. Например, если хотите собирать IPадреса своих посетителей, УРЛы, по которым они ходят или страницы, откуда пришли, время. При добавлении с задержкой скрипт отработает почти мгновенно, еще до выполнения операции.

Операция UPDATE идет в три этапа: поиск того, что будете менять, затем запись данных, обновление индексов. При этом, чем больше таблица, тем дольше поиск. Если есть индексы, то операция кешируется и выполняется достаточно быстро. Но сам процесс очень емкий. И только дурак не догонит, что большая таблица со множеством индексов и записей, будет тормозить при UPDATE. INSERT же выполняется одним залпом, очень быстро. Поэтому обычно используют аддитивные записи (вставками INSERT) во временные таблицы, потом блокируют основные талицы, суммируют обновления, и плюют их в основную таблицу. Получается, что в основном, главные таблицы работают только в режиме вывода, а обновления идут гораздо реже и быстрее. Например, можно копить данные о загрузках новостей во временной таблице, а по крону или иным образом обновлять счетчик каждые 10 минут (или реже). Это ускорит работу сервера.

При запросах SELECT * FROM таблица скрипт получит все поля данной таблицы. А нужно ли это? Использование * ведет к лишнему расходу ресурсов. Гораздо эффективнее использовать точные названия полей, которые нужны скрипту. Например: SELECT id,name FROM таблица. При таком запросе передача займет меньше времени и понадобится меньше ресурсов. Старайтесь ограничивать вывод при помощи директивы LIMIT. Это также ускоряет вывод.

Поиск по БД идет быстрее если вместо LIKE '%слово%', ставить 'слово%'. Операции с шаблонами регулярных выражений кешируются только в том случае, если в начале отсутствует символ %. Поэтому при построении поисковых запросов с LIKE избегайте начинающих символов %.

При построении таблиц для наиболее используемых полей (при поиске, сортировке и т.д.) обязательно создавайте индексы. Без индексов таблицы будут сильно тормозить. Индексы служат для кеширования и позволяют существенно ускорить вывод данных из таблиц. При этом таблицы будут занимать больше места на диске и в памяти. Но это в наше время не проблема.

Используйте надлежащий тип полей для своих записей. Тип TINYINT занимает 1 байт - самый быстрый. Таблицы с MEDIUMINT быстрее таблиц с INT. Если ставить полям свойство NOT NULL, то в целом их работа будет быстрее. VARCHAR медленее CHAR, поэтому таблицы переменной длины (где есть тип VARCHAR или TEXT) занимают меньше дискового пространства, но работают медленнее.

По своему опыту скажу, что для большинства сайтов подходят изложенные советы по работе с MySQL. Чтобы еще больше ускорить свой сервер, советую частоиспользуемые операции проводить по крону выделенными процессами и писать данные в различные файлы. Например, раз в 20 минут запускать скрипт, который будет создавать файл с новостями. Или например, генерить файл с новостями при их добавлениях или обновлениях. Таким образом, вы экономите на каждом обращении к БД. Интерактивность при этом не теряется, а производительность увеличивается во много раз. Особенно, повторяю, при высокой посещаемости ресурса. Старайтесь отделить интерактивные операции от фоновых. Например, на ПротоПлексе работает один интерактивный движок, но в фоне по заданиям трудятся с десяток различных роботов, которые генерируют часто вызываемые страницы, рассылают письма и т.д. Крупный сайт - это не только то, что вы видите, но и бек-енд (обратная сторона). В фоновом режиме можно быстро и эффективно готовить контент, освобождая основной движок от лишней работы.

В общем, основы должны быть всем понятны. Дробите все на мелочи, будь то запросы, таблицы или операции. Структура БД должна быть такой, чтобы не выполнялось ничего лишнего. Регулярно проводите OPTIMIZE на таблицах с переменной длиной, особенно, если в них идут удаления записей. Тестируйте свои запросы на скорость, упрощайте их.

Бурное развитие телекоммуникаций застало приход нового тысячелетия в новом витке технологических преобразований. Не остался в стороне и Web-Hosting как одна из профилирующих услуг интернет-сервиса. И если стремительное развитие IT характеризовалось, прежде всего, широко представленным предложением виртуального (в т.ч. бесплатного) хостинга, то новое десятилетие отмечает возросший интерес к разного рода технологиям выделенных серверов (dedicated servers) и co-location.

Что такое co-location? Co-location (colocation, collocation) дословно - это размещение физической машины клиента в специально оборудованном помещении провайдера на его технической площадке (в дата-центре). Помимо собственно размещения в базовый набор услуг по co-location входит:

Предоставление определенного объема предоплаченного трафика (входящего или исходящего, в зависимости от провайдера) или полосы пропускания;

Подключение к внешним каналам с высокой пропускной способностью (от 100 Мбит/c), наличие резервных каналов;

Повышенный уровень безопасности (система бесперебойного электропитания, климат-контроль, backup, охрана от физического проникновения посторонних на техническую площадку и т.д.);

Круглосуточная поддержка;

Оперативное устранение неисправностей непосредственно "на месте" (on-site).

Смежной с co-location является услуга аренды выделенного сервера (сервер не принадлежит клиенту, а взят в аренду у провайдера). В базовый набор услуг при аренде выделенного сервера обычно входит в дополнение к выше перечисленному :

Программное обеспечение для управления функциями сервера;

Предустановленное серверное программное обеспечение.

Услуга аренды сервера интересна в большей степени клиентам, территориально удаленным от коммуникационных центров (в России это Москва и Санкт-Петербург), а также тем, кто не хочет вкладывать деньги в покупку сервера, и тем у кого нет возможности инсталировать сервер своими силами, т.к. для этого нужно обладать знаниями системного администратора.

Co-location и dedicated существенно расширяют возможности веб-узла и являются единственно возможным решением для некоторых интернет-проектов. Как правило, к услугам аренды и размещения сервера прибегают при высоких требованиях к безопасности, потреблении большого объема трафика, высокой нагрузке на вычислительные мощности. Ведь при виртуальном хостинге ресурсы сервера делятся на всех клиентов размещенных на нем, и в случае появления высоко загруженного ресурса на сервере, вероятен отказ в обслуживании. Кроме того, безопасность виртуального хостинга вызывает большие сомнения: в 80% случаев взломы таких серверов производятся самими же клиентами. Немаловажным фактором при выборе выделенного сервера является возможность использования различного программного обеспечения и полный контроль над сервером. Последнее обстоятельство позволяет реализовать проект любой сложности с гарантированной защищенностью данных; для высоко загруженных проектов возможна реализация распределения вычислительной и сетевой нагрузки по нескольким серверам.

Среди проектов, решение которых в сети Интернет требует услуги co-location или выделенного сервера, следует назвать:

поисковые системы (www.yandex.ru)

фото-галереи (www.alenmax.ru)

виртуальные магазины (www.ozon.ru)

хостинг-провайдеры (www.alexhost.ru)

on-line базы данных (www.integrum.ru)

крупные проекты (www.uptime.ru)

интернет-версии оффлайновых СМИ (www.comprice.ru)

сайты с большим трафиком (www.mail.ru)

особо важные проекты (www.government.ru)

порталы (www.interpress.ru)

Несмотря на непространственную природу Интернет, широкое распространение спроса на услуги co-location в последнее время является своеобразной реакцией на распространение виртуального хостинга. Можно сказать, что в случае заключения контракта на co-location абонент покупает прежде всего определенное географическое место. Это место может характеризоваться особым географическим положением провайдера, включенностью в оптимальную телекоммуникационную инфраструктуру или, что тоже важно, хотя бы как психологический фактор, относительной близостью к главному офису заказчика.

Учитывая все эти факторы можно уверенно прогнозировать стремительное развитие данного вида web-услуг в Санкт-Петербурге. Данный регион - являющийся важнейшим телекоммуникационным центром России, местом, где пересекаются основные магистральные линии, связывающие страну с мировыми коммуникациями, - является вторым по экономической значимости регионом РФ. Более низкая по отношению к Москве затратная часть IT-бизнеса, высокий профессиональный уровень кадров, быстрое экономическое развитие региона в целом позволяют прогнозировать развитие спроса на услуги co-location и dedicated на петербургском рынке.

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

Что интересно, еще буквально пару-тройку лет назад под хостингом только это и понималось - размещение и обеспечение доступа. В большинстве случаев это так и выглядело - ваша страничка где-то там лежала, периодически откликаясь на попытки ее посмотреть, а нередко и не откликалась, причем когда кто-то из ваших знакомых интересовался, в чем там дело, вы только криво усмехались и отвечали что-то вроде: "Да опять у хостера какие-то проблемы".


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

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

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


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

И при всем этом богатстве услуг вполне серьезный хостинг стал стоить совсем небольших денег - $5, $10, $15 или $20, в зависимости от дисковой квоты и набора предоставляемых сервисов. Причем уровень стоимости похожих пакетов услуг у разных хостинг-провайдеров отличается весьма незначительно. Не бывает такого, чтобы у одного хостинг-провайдера, скажем так, оптимальный хостинговый пакет стоил $10, а у другого - $30. Разница обычно составляет буквально два-три доллара. Но вот как раз эти ничтожные пара долларов в месяц могут означать весьма существенные отличия в уровне и видах предоставляемых услуг.

Мне не раз приходилось слышать разговоры из серии: "Ну, и зачем ты в этой конторе хостишься, когда вон у тех - и оплата ниже на два бакса, и дискового пространства предоставляют больше, и список сервисов - две страницы?". Но потом, когда пользователь, соблазненный экономией двух долларов в месяц и списком сервисов на две страницы, переходил на нового хостинг-провайдера, вдруг выяснялось, что техподдержка там отвечает на звонки с 11 до 17, кроме выходных, причем как они отвечают - так лучше бы вообще не отвечали; что сайт имеет тенденцию вдруг падать и не подниматься, потому что вырубилось электричество, защиты у провайдера нет, так что все серверы полегли, а поднялись после появления электричества далеко не все, но никто и не почесался; что из заявленного длинного списка сервисов реально представлена дай бог половина, причем из них восемьдесят процентов - вещи, которые никогда не понадобятся, зато многое из того, что действительно нужно, работает через пень-колоду, и так далее. И становится не сильно понятно, зачем такие проблемы из-за каких-то двух долларов в месяц? Стоит оно того или нет?

Или наоборот. Бывает так, что вебмастер (или организация) сели к какому-то хостинг-провайдеру, мучаются с его ненавязчивым сервисом, а переходить в другое место - боятся, потому что, дескать, "от добра добра не ищут". От добра - точно, не ищут. Но в данном случае речь идет совсем не о добре, а о некачественном предоставлении услуг.


Понятие хостинга стало включать в себя большой набор всевозможных дополнительных видов услуг
Закончились времена доморощенных хостеров. Точнее, почти закончились, потому что где-то еще остались конторы, предоставляющие хостинг на кошмарном уровне девяностых годов прошлого столетия. Но они очень скоро отомрут, потому что не могут, не умеют и не хотят оказывать эту услугу так, как полагается на современном уровне, а сегодняшнего клиента уже не удовлетворяют фразы "не волнуйтесь, завтра починим" или "пока нет, но скоро будет". Ему нужно сейчас, в полном объеме и качественно.

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

Конечно, тут многое зависит от ваших личных требований к хостингу. Потому что если вам нужно разместить страничку с парой фотографий и текстом "Когда-нибудь здесь будет крутая страница", тогда, конечно, вас мало будет интересовать охрана дата-центра и защита электропитания. Но в этом случае вам и нормальный хостинг не нужен - достаточно просто разместить страничку на одном из бесплатных серверов. А вот в случае размещения серьезного проекта, корпоративного ресурса и так далее все эти вопросы обязательно нужно выяснить, потому что, например, неответ корпоративного ресурса в течение какого-то времени может обернуться серьезными финансовыми потерями.

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

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

Информация в локальных сетях, как правило, передается отдельными порциями, кусками, называемыми в различных источниках пакетами (packets), кадрами (frames) или блоками. Причем предельная длина этих пакетов строго ограничена (обычно величиной в несколько килобайт). Ограничена длина пакета и снизу (как правило, несколькими десятками байт). Выбор пакетной передачи связан с несколькими важными соображениями.


Информация в локальных сетях, как правило, передается отдельными порциями, кусками, называемыми в различных источниках пакетами (packets), кадрами (frames) или блоками. Причем предельная длина этих пакетов строго ограничена (обычно величиной в несколько килобайт). Ограничена длина пакета и снизу (как правило, несколькими десятками байт). Выбор пакетной передачи связан с несколькими важными соображениями.

Локальная сеть, как уже отмечалось, должна обеспечивать качественную, прозрачную связь всем абонентам (компьютерам) сети. Важнейшим параметром является так называемое время доступа к сети (access time), которое определяется как временной интервал между моментом готовности абонента к передаче (когда ему есть, что передавать) и моментом начала этой передачи. Это время ожидания абонентом начала своей передачи. Естественно, оно не должно быть слишком большим, иначе величина реальной, интегральной скорости передачи информации между приложениями сильно уменьшится даже при высокоскоростной связи.

Ожидание начала передачи связано с тем, что в сети не может происходить несколько передач одновременно (во всяком случае, при топологиях шина и кольцо). Всегда есть только один передатчик и один приемник (реже – несколько приемников). В противном случае информация от разных передатчиков смешивается и искажается. В связи с этим абоненты передают свою информацию по очереди. И каждому абоненту, прежде чем начать передачу, надо дождаться своей очереди. Вот это время ожидания своей очереди и есть время доступа.

Если бы вся требуемая информация передавалась каким-то абонентом сразу, непрерывно, без разделения на пакеты, то это привело бы к монопольному захвату сети этим абонентом на довольно продолжительное время. Все остальные абоненты вынуждены были бы ждать окончания передачи всей информации, что в ряде случаев могло бы потребовать десятков секунд и даже минут (например, при копировании содержимого целого жесткого диска). С тем чтобы уравнять в правах всех абонентов, а также сделать примерно одинаковыми для всех них величину времени доступа к сети и интегральную скорость передачи информации, как раз и применяются пакеты (кадры) ограниченной длины. Важно также и то, что при передаче больших массивов информации вероятность ошибки из-за помех и сбоев довольно высока. Например, при характерной для локальных сетей величине вероятности одиночной ошибки в 10-8пакет длиной 10 Кбит будет искажен с вероятностью 10-4, а массив длиной 10 Мбит – уже с вероятностью 10-1. К тому же выявить ошибку в массиве из нескольких мегабайт намного сложнее, чем в пакете из нескольких килобайт. А при обнаружении ошибки придется повторить передачу всего большого массива. Но и при повторной передаче большого массива снова высока вероятность ошибки, и процесс этот при слишком большом массиве может повторяться до бесконечности.

С другой стороны, сравнительно большие пакеты имеют преимущества перед очень маленькими пакетами, например, перед побайтовой (8 бит) или пословной (16 бит или 32 бита) передачей информации.

Дело в том, что каждый пакет помимо собственно данных, которые требуется передать, должен содержать некоторое количество служебной информации. Прежде всего, это адресная информация, которая определяет, от кого и кому передается данный пакет (как на почтовом конверте – адреса получателя и отправителя). Если порция передаваемых данных будет очень маленькой (например, несколько байт), то доля служебной информации станет непозволительно высокой, что резко снизит интегральную скорость обмена информацией по сети.

Существует некоторая оптимальная длина пакета (или оптимальный диапазон длин пакетов), при которой средняя скорость обмена информацией по сети будет максимальна. Эта длина не является неизменной величиной, она зависит от уровня помех, метода управления обменом, количества абонентов сети, характера передаваемой информации, и от многих других факторов. Имеется диапазон длин, который близок к оптимуму.

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

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

Рис. 4.1. Передача пакетов в сети между двумя абонентами

В частном случае (рис. 4.1) все эти пакеты могут передаваться одним абонентом (когда другие абоненты не хотят передавать). Но обычно в сети чередуются пакеты, посланные разными абонентами (рис. 4.2).

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

Рис. 4.2. Передача пакетов в сети между несколькими абонентами

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

Но существуют некоторые общие принципы формирования структуры пакета, которые учитывают характерные особенности обмена информацией по любым локальным сетям.

Чаще всего пакет содержит в себе следующие основные поля или части (рис. 4.3):

Типичная структура пакета

Рис. 4.3. Типичная структура пакета

* Стартовая комбинация битов или преамбула, которая обеспечивает предварительную настройку аппаратуры адаптера или другого сетевого устройства на прием и обработку пакета. Это поле может полностью отсутствовать или же сводиться к единственному стартовому биту.
* Сетевой адрес (идентификатор) принимающего абонента, то есть индивидуальный или групповой номер, присвоенный каждому принимающему абоненту в сети. Этот адрес позволяет приемнику распознать пакет, адресованный ему лично, группе, в которую он входит, или всем абонентам сети одновременно (при широком вещании).
* Сетевой адрес (идентификатор) передающего абонента, то есть индивидуальный номер, присвоенный каждому передающему абоненту. Этот адрес информирует принимающего абонента, откуда пришел данный пакет. Включение в пакет адреса передатчика необходимо в том случае, когда одному приемнику могут попеременно приходить пакеты от разных передатчиков.
* Служебная информация, которая может указывать на тип пакета, его номер, размер, формат, маршрут его доставки, на то, что с ним надо делать приемнику и т.д.
* Данные (поле данных) – это та информация, ради передачи которой используется пакет. В отличие от всех остальных полей пакета поле данных имеет переменную длину, которая, собственно, и определяет полную длину пакета. Существуют специальные управляющие пакеты, которые не имеют поля данных. Их можно рассматривать как сетевые команды. Пакеты, включающие поле данных, называются информационными пакетами. Управляющие пакеты могут выполнять функцию начала и конца сеанса связи, подтверждения приема информационного пакета, запроса информационного пакета и т.д.
* Контрольная сумма пакета – это числовой код, формируемый передатчиком по определенным правилам и содержащий в свернутом виде информацию обо всем пакете. Приемник, повторяя вычисления, сделанные передатчиком, с принятым пакетом, сравнивает их результат с контрольной суммой и делает вывод о правильности или ошибочности передачи пакета. Если пакет ошибочен, то приемник запрашивает его повторную передачу. Обычно используется циклическая контрольная сумма (CRC). Подробнее об этом рассказано в главе 7.
* Стоповая комбинация служит для информирования аппаратуры принимающего абонента об окончании пакета, обеспечивает выход аппаратуры приемника из состояния приема. Это поле может отсутствовать, если используется самосинхронизирующийся код, позволяющий определять момент окончания передачи пакета.

Вложение кадра в пакет

Рис. 4.4. Вложение кадра в пакет

Нередко в структуре пакета выделяют всего три поля:

* Начальное управляющее поле пакета (или заголовок пакета), то есть поле, включающее в себя стартовую комбинацию, сетевые адреса приемника и передатчика, а также служебную информацию.
* Поле данных пакета.
* Конечное управляющее поле пакета (заключение, трейлер), куда входят контрольная сумма и стоповая комбинация, а также, возможно, служебная информация.

Как уже упоминалось, помимо термина "пакет" (packet) в литературе также нередко встречается термин "кадр" (frame). Иногда под этими терминами имеется в виду одно и то же. Но иногда подразумевается, что кадр и пакет различаются. Причем единства в объяснении этих различий не наблюдается.

В некоторых источниках утверждается, что кадр вложен в пакет. В этом случае все перечисленные поля пакета кроме преамбулы и стоповой комбинации относятся к кадру (рис. 4.4). Например, в описаниях сети Ethernet говорится, что в конце преамбулы передается признак начала кадра.

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

Во избежание путаницы, в данной книге термин "пакет" будет использоваться как более понятный и универсальный.

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

Пример простейшего протокола показан на рис. 4.5.

Пример обмена пакетами при сеансе связи

Рис. 4.5. Пример обмена пакетами при сеансе связи

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

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

Многоуровневая система вложения пакетов

Рис. 4.6. Многоуровневая система вложения пакетов

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

Обратный процесс последовательной распаковки данных приемником называется декапсуляцией пакетов.