Внешняя компонента позволяющая строить аналитические кубы на основании таблицы значений, сохранять состояния измерений, экспортировать в Excel с сохранением состояния группировок и ещё много всего...
В архиве 2 файла Пример использования OLAP.epf и внешняя компонента ActiveX OLAP.ocx регистрируется regsvr32 "..\Olap.ocx"
В данной статье приведены общие сведения об организации работы системы 1С:Предприятие с распределенной информационной базой (ИБ). Также описаны внутренние особенности организации механизма работы с распределенными данными для того, чтобы специалисты, осуществляющие конфигурирование и администрирование распределенных систем могли лучшее понимать выполняемые системой действия. Данная информация может также быть использована для оценки дополнительных затрат ресурсов системы, расходуемых на поддержание распределенной информационной базы.
Так как средства системы 1С:Предприятие для работы с распределенными информационными базами поставляются отдельно, сначала кратко остановимся на назначении и основных принципах организации работы системы 1С:Предприятие с территориально удаленными подразделениями.
Назначение и основные принципы
В тех случаях, когда предприятие представляет собой территориально распределенную структуру, зачастую сохраняется потребность в ведении единой системы учета. То есть необходимо иметь возможность работать в едином пространстве документов, получать отчеты, отражающие состояние дел как в территориально удаленных подразделениях предприятия, так и на предприятии в целом и т.п. При этом не всегда имеется возможность организовать работу всех подразделений с единой информационной базой в режиме он-лайн.
Для решения подобных задач предназначена компонента "Управление распределенными ИБ". С помощью указанной компоненты можно организовать двухуровневую структуру информационных баз (ИБ) системы 1С:Предприятие, состоящую из одной центральной и нескольких периферийных информационных баз, работающих с единой конфигурацией. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.
Содержимое информационных баз синхронизируется путем переноса измененных объектов данных между каждой из периферийных и центральной ИБ. Для переноса данных используются так называемые файлы переноса данных. Перенос изменений выполняется только между центральной и периферийными ИБ. Перенос данных непосредственно между периферийными ИБ невозможен. Поэтому изменения данных, произведенные в одном из периферийных узлов распределенной ИБ попадают в другие периферийные узлы только через центральную ИБ.
В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.
В некоторых случаях может возникнуть необходимость в том, чтобы объекты того или иного типа никогда не попадали в те или иные узлы распределенной ИБ или никогда не покидали места своего создания. Для обеспечения такой возможности предназначен механизм настройки параметров миграции объектов. С его помощью можно ограничить распространение изменений объектов того или иного вида. Кроме того, в версии 7.7 системы 1С:Предприятие можно создавать периферийные ИБ, которые будут принимать информацию о измененных объектах из центральной ИБ, но не будут передавать изменения, сделанные в них самих.
Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.
Однако, для того, чтобы документы, элементы справочников и другие объекты, созданные в разных узлах распределенной ИБ, имели заведомо непересекающиеся пространства номеров, кодов и т. п., может потребоваться внести в конфигурацию некоторые изменения. Также изменения в конфигурации должны вноситься при необходимости обеспечить специальные ограничения работы пользователей на периферийных информационных базах.
Для переноса измененных объектов в распределенной ИБ и для первичного создания периферийной ИБ используется файл переноса данных. Он представляет собой упакованный (сжатый) файл, содержащий объекты информационной базы (все при создании периферийной ИБ или измененные при передаче изменений) в специальном формате. Формат данного файла не предназначен для использования его способами отличными от тех, которые предусмотрены механизмами выгрузки/загрузки и передачи изменений. Файл переноса фактически отражает содержимое объектов информационной базы в формате, не зависящем от формата базы данных. Это позволяет использовать в распределенной информационной системе в различных узлах различные форматы хранения данных, поддерживаемые системой 1С:Предприятие (DBF/CDX и MS SQL Server).
Регистрация изменений
Перенос измененных данных производится "пообъектно". То есть единицей переноса данных является так называемый ведущий объект. С точки зрения работы в распределенной информационной базе в 1С:Предприятии существуют следующие типы ведущих объектов:
константа,
элемент справочника,
документ,
календарь,
счет бухгалтерского учета,
типовая операция.
Вместе с документами переносятся все действия, выполняемые ими в процессе проведения: движения регистров, акты расчета, бухгалтерская операция, проводки. В случае, если при проведении документа производятся изменения периодических реквизитов элемента справочника, то производится перенос всего элемента справочника.
Регистрация изменений объектов производится автоматически при любом изменении объекта, независимо от того каким способом это изменение производилось (интерактивно или из встроенного языка). Кроме того в версии 7.7 системы 1С:Предприятие для таких объектов как элементы справочников и документы появилась возможность управления регистрацией изменений. Для этого у соответствующих объектов метаданных введен признак "Автоматическая регистрация изменений". Если этот признак установлен (значение по умолчанию), то автоматическая регистрация производится, а если признак сброшен, то регистрация не производится и изменения объектов в распределенной ИБ не распространяются. Но и в данном случае, при выполнении записи изменений объектов из встроенного языка можно управлять регистрацией изменений с помощью метода встроенного языка РегистрацияИзменений().
Регистрация изменений ведущих объектов производится в специальной служебной таблице. При этом фиксируются следующие данные об изменении объекта:
Сам ведущий объект;
Идентификатор той ИБ, в которую должно быть передано изменение;
Идентификатор ИБ, в которую должно быть передано изменение, служит для отслеживания переноса данных в каждую из ИБ, с которой данная ИБ обменивается данными. Таким образом, при изменении какого-либо объекта в центральной ИБ в таблицу будет помещено по одной записи для каждой из зарегистрированных периферийных информационных баз. Если же изменение объекта происходит в периферийной ИБ, то в таблицу будет занесена только одна запись, соответствующая центральной ИБ, так как каждая из периферийных ИБ непосредственно взаимодействует только с центральной.
Заметим, что удаление объекта является частным случаем изменения. Оно также помечается в таблице регистрации изменений и передается при выгрузке.
Выгрузка и загрузка изменений
Каждая выгрузка изменений осуществляется в адрес конкретной ИБ. В файл переноса, создаваемый при выгрузке попадают все объекты, записи об изменениях которых содержатся в таблице регистрации изменений для данной ИБ.
Заметим, что выгружаются не изменения объектов, а сами измененные объекты. То есть, если в документе изменилось значение одного реквизита, то будет передаваться весь документ и он будет полностью перезаписан на той ИБ, в которую переносится. Как уже отмечалось, вместе с документом будут перенесены и сделанные им движения регистров, операция и проводки. Если изменяется любой реквизит справочника, то передается полностью весь элемент. При этом история периодических реквизитов передается целиком. Последнее означает, что изменения сделанные в истории периодического реквизита элемента на в двух ИБ не будут сливаться вместе.
В процессе выгрузки в таблице регистрации изменений отмечается выгрузка изменений объектов.
При загрузке файла переноса данных помимо загрузки измененных данных выполняется так называемый прием подтверждений.
В случае, когда пришло подтверждение на получение выгрузки, содержащей последнее изменение объекта, запись об изменении удаляется из таблицы регистрации. То есть записи об изменении объектов данных хранятся в таблице регистрации до тех пор, пока не будет получено подтверждение о доставке измененного объекта по назначению.
Причем выгрузка измененного объекта будет производиться до тех пор, пока не будет получено подтверждение, о доставке изменения. Это значит, что если выполнять перенос все время в одном направлении и не выполнять обратного переноса то объем файла переноса данных будет все время расти, так как каждый раз будут передаваться все объекты, измененные после последнего полученного подтверждения.
При загрузке изменений объектов из периферийной ИБ в центральную, в таблицу регистрации изменений (если, конечно, параметры миграции настроены соответствующим образом) заносятся записи, указывающие, что загруженные из периферийной ИБ изменения объектов должны быть переданы в другие периферийные ИБ.
Изменения конфигурации
Как уже отмечалось, при работе с распределенной ИБ, конфигурация системы может быть изменена только в центральном узле.
Для регистрации изменений конфигурации и передачи ее на периферийные ИБ используется тот же механизм, что и для объектов данных. При записи измененной конфигурации, в таблицу регистрации изменений объектов по числу известных периферийных ИБ заносятся записи, фиксирующие факт изменения конфигурации.
После записи измененной конфигурации в распределенной ИБ складывается такая ситуация, что центральная и периферийные ИБ работают фактически с разными конфигурациями. В таком состоянии созданные на периферийной ИБ файлы переноса данных не могут быть загружены на центральной ИБ по той причине, что в условиях различных конфигураций содержащаяся в файле информация не может быть правильно интерпретирована. Обмен будет восстановлен только после того, как в периферийную ИБ будет загружена измененная конфигурация с центральной ИБ. То есть после изменения конфигурации требуется выполнить перенос из центральной ИБ в каждую из периферийных, а уже затем выполнять перенос из периферийных ИБ в центр.
Перенос измененной конфигурации в периферийные ИБ осуществляется тем же способом, что и перенос измененных объектов данных. В процессе очередной выгрузки из центральной ИБ, в файл переноса данных целиком включается измененная конфигурация, если, конечно, в таблице регистрации изменений содержится запись о том, что измененную конфигурацию следует передать в соответствующую периферийную ИБ. Выгрузка конфигурации также будет производиться до получения извещения о приеме измененной конфигурации.
Заметим, что конфигурация считается измененной при любых изменениях метаданных, форм, модулей, таблиц конфигурации, наборов прав, пользовательских интерфейсов, описаний. В состав конфигурации не входит список пользователей, а также внешние по отношению к файлу конфигурации (1CV7.MD) файлы (внешние отчеты, отдельно записанные таблицы и тексты). И эти внешние файлы не переносятся механизмом управления распределенной ИБ. Поэтому при конфигурировании распределенной системы не рекомендуется использовать в конфигурации находящиеся в отдельных файлах модули, таблицы и отчеты.
Для изменения уже работающей конфигурации можно рекомендовать использовать механизм загрузки измененной конфигурации. Он позволяет специалисту скопировать конфигурацию, выполнить в ней все необходимые изменения, отладить внесенные изменения (этот процесс может занять и несколько дней), а затем загрузить измененную конфигурацию в центральную ИБ, после чего изменения будут распространены на все периферийные ИБ с очередной передачей изменений. Такая последовательность позволит избежать многократной передачи измененной конфигурации в периферийные ИБ в процессе ее модернизации.
При загрузке файла переноса данных на периферийной ИБ, этап загрузки измененной конфигурации (если, конечно, она содержится в файле переноса данных) предшествует этапу загрузки измененных объектов данных. В случае неудачного завершения загрузки конфигурации, загрузка объектов данных производиться не будет и информационная база останется в том же состоянии, что и была до начала загрузки.
Загрузка измененной конфигурации может завершиться неудачей, если измененная конфигурация не соответствует существующим данным. Например, было уменьшено число уровней справочника, а новое число уровней оказывается меньшим, чем фактически содержащееся в справочнике или в других подобных случаях. Если такое произошло, то следует привести данные в соответствие с новой конфигурацией или изменить конфигурацию в центральной ИБ и заново произвести выгрузку, чтобы ликвидировать возникшее противоречие.
Коллизии
При работе в реальных распределенных ИБ один и тот же объект может изменяться одновременно в различных узлах распределенной ИБ. И при переносе измененных объектов из одной ИБ в другую может случиться так, что в какую-либо ИБ будет загружаться объект, зарегистрированный в самой этой ИБ как измененный. Такая ситуация носит название коллизии. Приведем описание действий системы в наиболее типовых вариантах коллизий.
Один и тот же объект изменен более чем в одной ИБ.
Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются.
Объект, измененный в одной ИБ, удален в другой.
В данном случае принцип заключается в том, что изменение всегда "главнее" удаления. В случае, если на центральную ИБ прибывает файл переноса, в котором содержится информация, что некоторый объект удален на периферийной ИБ, то в центральной ИБ объект не удаляется, а в записи таблицы регистрации изменений данный объект помечается как измененный. То есть при очередном обмене объект будет восстановлен в той ИБ, в которой он был удален, причем само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ.
Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.
При загрузке изменений, если загружается информация об удалении объектов, автоматически включается механизм контроля ссылочной целостности и выполняется проверка наличия ссылок в данной ИБ на объекты, которые переданы как удаленные.
В случае обнаружения коллизии такого рода, вне зависимости от того на какой из ИБ она была обнаружена, выполняется следующее: удаление не выполняется, а в таблицу регистрации изменений заносится запись о том, что объект должен быть перенесен в адрес той ИБ, из которой была прислана информация о его удалении.
При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Таким образом, управление распределенной информационной базой имеет определенную стратегию автоматического разрешения любых коллизий с описанными приоритетами. Однако, в реальных условиях рекомендуется средствами конфигурации определить возможные действия пользователей на различных узлах таким образом, чтобы исключить или минимизировать вероятность возникновения коллизий. Основным путем является определения средствами конфигурации "ответственного" узла за каждый ведущий объект в распределенной ИБ и ограничение всем остальным возможности его редактирования и удаления. Определение "ответственных" должно происходить исходя из логики работы предприятия. Очевидно, что многие виды объектов можно разрешить изменять только в центральной ИБ (например, список складов). Для многих объектов можно рекомендовать средствами встроенного языка установить возможность изменения только на той ИБ, на которой они созданы, например для документов.
Параметры миграции
С помощью настройки параметров миграции можно ограничивать области распространения изменений объектов. Настройка параметров миграции происходит по видам "ведущих" объектов. То есть для каждого вида "ведущих" объектов можно определить конкретную настройку параметров миграции. В настройке параметров миграции объектов ведущую роль играет выбор того или иного варианта области распространения изменений объектов данного вида. Существуют три варианта настройки области распространения:
Все информационные базы. Данный вариант настройки используется по умолчанию для всех объектов. В этом случае любые изменения объектов данного типа будут распространяться по всем узлам распределенной ИБ. Этот вариант обеспечивает полную синхронизацию объектов данного вида во всей распределенной ИБ. Очевидно, что этот вариант наиболее прост для конфигурирования.
Место создания. Данный вариант настройки также является довольно простым. В этом случае изменения объекта не передаются в другие ИБ. При такой настройке параметров миграции, объект данного вида никогда не "покидает" места своего создания и не появляется в других ИБ. Однако при выборе данного варианта следует учитывать возможные ссылки на объекты данного вида из объектов других видов, имеющих другие параметры миграции. Например, если установить такой вариант для справочника, и в документах, которые участвуют в обмене, будет содержаться реквизит типа справочник данного вида, то при переносе документа получится неразрешенная ссылка.
Место создания и центр. При таком варианте настройки области распространения объектов существенную роль играет понятие места создания объекта. Местом создания объекта считается ИБ, в которой был создан конкретный объект. Естественно, что различные объекты одного вида могут быть созданы в различных ИБ. Однако место создания объекта может быть определено не для всех видов "ведущих" объектов. Для таких объектов как константы, календари или корректные проводки место создания не определено. Поэтому для этих видов объектов вариант настройки "Место создания и центр" не может быть установлен.
В случае выбора такого варианта области распространения, объекты данного вида помимо места их создания попадают еще и на центральную ИБ. То есть, в случае, если для некоторого вида объектов установлена область распространения "Место создания и центр", то для объектов этого вида, созданных на периферийной ИБ, их изменения будут передаваться между местом их создания и центральной ИБ. Для объектов того же вида, созданных на центральной ИБ, изменения не будут передаваться никуда. С помощью такого варианта области распространения можно добиться такого эффекта, что все объекты того или иного вида будут "собираться" на центральной ИБ, а на любой из периферийных ИБ будут находиться только те объекты, для которых она является местом создания.
В случае выбора области распространения "Место создания и центр", для вида объекта можно задать перечень периферийных узлов распределенной ИБ, которые дополнительно включаются в область распространения всех объектов данного вида. Этот перечень задается как список кодов периферийных ИБ, разделенный запятыми. При задании кодов ИБ допускается использование символов-заменителей '*'. Символ-заменитель должен завершать последовательность символов, образующих код одной или нескольких периферийных ИБ. Таким образом, "A*" представляет собой обозначение всех периферийных ИБ, коды которых начинаются символом 'А'. Последовательность "A*B" является ошибочной, так как символ '*' не завершает последовательность символов, представляющих код периферийной ИБ.
Кроме того, как отмечалось выше, дополнительной возможностью управлять распространением изменений объектов в версии 7.7 системы 1С:Предприятие является особый вид периферийных ИБ, которые получают изменения из центральной ИБ, а сами информацию о сделанных в них изменениях не передают. Для создания периферийной ИБ такого рода, надо при ее инициализации указать признак "Только получатель".
Отдельно стоит рассмотреть случай, когда параметры миграции объектов изменяются в процессе изменения конфигурации уже работающей системы. Изменения параметров миграции для каждого из объектов производится независимо от других. То есть, Конфигуратор не отслеживает ссылки между объектами при настройке параметров миграции. Таким образом, при определенных вариантах настройки параметров миграции у некоторых объектов могут появиться ссылки, указывающие "никуда". Ответственность за сохранение ссылочной целостности в распределенных ИБ возлагается на лицо, занимающееся конфигурированием системы. Общим правилом настройки параметров миграции является определение области миграции для конкретного вида объектов равной более широкой, чем область миграции ссылающихся на него объектов. Например, для справочника область миграции должна быть определена не уже, чем области миграции документов и справочников, в которых есть реквизиты типа "справочник" данного вида. Если, например, измерение регистра имеет тип "справочник" данного вида, то область миграции справочника должна покрывать области миграции всех документов, которые могут записать движения данного регистра.
При изменении параметров миграции того или иного объекта система старается привести имеющиеся данные в соответствие с новыми параметрами. Общим принципом здесь является то, что при изменении параметров миграции объекты никогда ни в каком узле распределенной ИБ не удаляются. Даже в том случае, если в соответствии с вновь установленными параметрами миграции их там быть не должно. Изменения производятся лишь в таблице регистрации изменений. Рассмотрим случаи изменения параметров миграции объектов подробнее.
Наиболее простой случай - это смена любого из вариантов области распространения на вариант "Место создания". В этом случае из таблицы регистрации изменений удаляются все записи по данному виду объектов. То есть все изменения объектов, еще не переданные в другие ИБ, не будут переданы. При этом, все объекты для которых данная ИБ не является местом создания, не будут удалены. Просто их изменения (как и изменения других объектов данного вида) не будут больше передаваться в другие ИБ.
Следующий случай - это смена области распространения "Место создания" на варианты "Все информационные базы" или "Место создания и центр". В этом случае в таблицу регистрации изменений заносятся записи для передачи всех объектов, для которых текущая ИБ является местом создания во все ИБ, в которые должны передаваться изменения в соответствии с вновь заданной настройкой. В случае, если такая смена производится для объектов, для которых место создания не определено (константы, календари, корректные проводки), то записи в таблицу регистрации изменений будут произведены только в центральной ИБ. Этими двумя вариантами и ограничиваются возможные случаи изменения параметров миграции для такого рода объектов. Все остальные случаи возможны только для тех объектов, для которых место создания можно определить.
При изменении области распространения объектов с "Место создания и центр" на "Все информационные базы", какие-либо действия предпринимаются только в центральной ИБ. В этом случае определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. После этого производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи состояния объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.
Последний и самый сложный случай - это изменение области распространения объектов с "Все информационные базы" на "Место создания и центр" или изменение списка дополнительных ИБ в варианте "Место создания и центр". Действия, производимые в данном случае различаются в зависимости от того, производятся они в центральной ИБ или в периферийной. В центральной ИБ для каждой из периферийных ИБ, не попавших в новый перечень дополнительно включаемых в область распространения, выполняется удаление из таблицы регистрации изменений записей соответствующих данному виду объектов, но только для тех объектов, для которых эта периферийная ИБ не является местом создания. Затем определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. Естественно, что в случае, если предыдущим вариантом настройки области распространения было "Все информационные базы", то этот список окажется пустым. Затем, как и в предыдущем случае, производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.
Проблемы конфигурирования и администрирования
При разработке конфигурации для распределенной ИБ проявляется ряд объективно существующих проблем, которые решаются как средствами конфигурации, так и административными решениями.
Очевидной проблемой, которая уже упоминалась выше, является уникальная и последовательная нумерация документов и элементов справочников. Для организации уникальной нумерации используется механизм префиксов. Для его включения в конфигурацию, прежде всего, следует выработать некоторую дисциплину, зависимости префикса от ИБ, в которой создается объект. В простейшем случае это может быть собственно код ИБ. Однако часто префикс может автоматически определяться на каждой ИБ, но не являться ее кодом, так как он может участвовать в печатных формах документов и должен быть понятным для пользователей системы. Более сложной задачей является обеспечение сквозной нумерации объектов без префиксов в случае, когда такая нумерация регламентируется нормативными документами. Особенно сложным является обеспечение строго последовательной нумерации. Очевидно, что полного решения данной проблемы не может быть в принципе, так как объекты создаваемые динамически в независимых системах не могут иметь строгой сквозной нумерации. Отчасти данная проблема решается с помощью введения диапазонов номеров, выделяемых для каждой ИБ. Следует заметить, что номера документов и коды справочников не являются внутренними идентификаторами и их уникальность для системы не обязательна. Это значит, что поддержку уникальность номеров и кодов можно отключить для тех видов, объектов, для которых она не нужна. Кроме того, средствами конфигурации можно организовать перенумерацию объектов, например в центральной ИБ. Однако следует иметь ввиду, что эти изменения будут передаваться как и любые другие изменения, что может вызвать достаточно большой объем передаваемых между узлами данных.
Более сложной проблемой является ситуация, когда возникает необходимость использования некоторого нового объекта в двух и более узлах одновременно, до осуществления передачи данных. Например, новый товар должен быть введен и на центральной ИБ и на периферийной. Важно понимать, что созданный ведущий объект системы 1С:Предприятие обладает некоторой сущностью - внутренним идентификатором, который уникален во всей распределенной системе. То есть один и тот же объект не может быть введен в двух узлах. Даже при полном соответствии кодов, номеров и всех данных это будут два разных объекта. Такой принцип необходим для четкой работы системы со всех точек зрения.
Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.
Поэтому, на наш взгляд, решение проблемы должно лежать в области администрирования системы. Технология работы пользователей должна быть построена таким образом, чтобы ввод объекта производился на одном узле.
В отдельных случаях может использоваться следующее решение. В справочник заранее вносится некоторое количество новых элементов со специальными кодами или в специальную группу. При появлении необходимости ввода нового товара реально не вводится новый элемент, а изменяется один этих элементов. При этом административными силами должно быть обеспечено идентичное изменение одного и того же "зарезервированного" объекта в тех узлах распределенной ИБ, в которой он должен быть использован до обмена данными. При обмене данными сами реквизиты элемента будут системой синхронизированы, а ссылки в других объектах, разумеется будут идентичными, так как использовался один и тот же объект.
В любых случаях следует учитывать, что раздельный ввод и использование объектов потребует от пользователей правильного ввода данных. Так, например, при вводе нового товара в двух узлах с разными ценами могут иметь место серьезные ошибки в оформлении документов.
Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".
Перед работой через протокол POP3 сервер прослушивает порт 110. Когда клиент хочет использовать этот протокол, он должен создать TCP соединение с сервером. Когда соединение установлено, сервер отправляет приглашение. Затем клиент и POP3 сервер обмениваются информацией пока соединение не будет закрыто или прервано.
Команды POP3 состоят из ключевых слов, за некоторыми следует один или более аргументов. Все команды заканчиваются парой CRLF (в Visual Basic константа vbCrLf). Ключевые слова и аргументы состоят из печатаемых ASCII символов. Ключевое слово и аргументы разделены одиночным пробелом. Ключевое слово состоит от 3-х до 4-х символов, а аргумент может быть длиной до 40-ка символов.
Ответы в POP3 состоят из индикатора состояния и ключевого слова, за которым может следовать дополнительная информация. Ответ заканчивается парой CRLF. Существует только два индикатора состояния: "+OK" - положительный и "-ERR" - отрицательный.
Ответы на некоторые команды могут состоять из нескольких строк. В этих случаях каждая строка разделена парой CRLF, а конец ответа заканчивается ASCII символом 46 (".") и парой CRLF.
POP3 сессия состоит из нескольких режимов. Как только соединение с сервером было установлено и сервер отправил приглашение, то сессия переходит в режим AUTHORIZATION (Авторизация). В этом режиме клиент должен идентифицировать себя на сервере. После успешной идентификации сессия переходит в режим TRANSACTION (Передача). В этом режиме клиент запрашивает сервер выполнить определённые команды. Когда клиент отправляет команду QUIT, сессия переходит в режим UPDATE. В этом режиме POP3 сервер освобождает все занятые ресурсы и завершает работу. После этого TCP соединение закрывается.
У POP3 сервера может быть INACTIVITY AUTOLOGOUT таймер. Этот таймер должен быт, по крайней мере, с интервалом 10 минут. Это значит, что если клиент и сервер не взаимодействуют друг с другом, сервер автоматически прерывает соединение и при этом не переходит в режим UPDATE.
Авторизация в протоколе POP3
Как только будет установлено TCP соединение с POP3 сервером, он отправляет приглашение, заканчивающееся парой CRLF, например:
Теперь POP3 сессия находится в режиме AUTHORIZATION. Клиент должен идентифицировать себя на сервере, используя команды USER и PASS. Сначала надо отправить команду USER, после которой в качестве аргумента следует имя пользователя. Если сервер отвечает положительно, то теперь необходимо отправить команду PASS, за которой следует пароль. Если после отправки команды USER или PASS сервер отвечает негативно, то можно поробовать авторизироваться снова или выйти из сесси с помощью команды QUIT. После успешной авторизации сервер открывает и блокирует maildrop (почтовый ящик). В ответе на команду PASS сервер сообщает сколько сообщений находится в почтовом ящике и передаёт их общий размер. Теперь сессия находится в режиме TRANSACTION. Подведём итоги с командами:
Команда: USER [имя]
Аргументы: [имя] - строка, указывающая имя почтового ящика
Описание: Передаёт серверу имя пользователя.
Возможные ответы:
* +OK name is a valid mailbox
* -ERR never heard of mailbox name
Примеры:
C: USER MonstrVB
S: +OK MonstrVB is a real hoopy frood
...
C: USER MonstrVB
S: -ERR sorry, no mailbox for frated here
* +OK maildrop locked and ready
* -ERR invalid password
* -ERR unable to lock maildrop
Примеры:
C: USER MonstrVB
S: +OK MonstrVB is a real hoopy frood
C: PASS mymail
S: +OK MonstrVB's maildrop has 2 messages (320 octets)
...
C: USER MonstrVB
S: +OK MonstrVB is a real hoopy frood
C: PASS mymail
S: -ERR maildrop already locked
Команда: QUIT
Аргументы: нет
Описание: Сервер завершает POP3 сессию и переходит в режим UPDATE. Возможные ответы:
* +OK
Примеры:
C: QUIT
S: +OK dewey POP3 server signing off
Основные команды (Transaction) протоколе в POP3
После успешной идентификации пользователя на сервере POP3 сессия переходит в режим TRANSACTION, где пользователь может передавать ниже следующие команды. После каждой из таких команд следут ответ сервера. Вот доступные команды в этом режиме:
Команда: STAT
Аргументы: нет
Описание: В ответ на вызов команды сервер выдаёт положительный ответ "+OK", за которым следует количество сообщений в почтовом ящике и их общий размер в символах. Сообщения, которые помечены для удаления не учитываются в ответе сервера.
Возможные ответы:
* +OK n s
Примеры:
C: STAT
S: +OK 2 320
Команда: LIST [сообщение]
Аргументы: [сообщение] - номер сообщения (необязательный аргумент)
Описание: Если был передан аргумент, то сервер выдаёт информацию о указанном сообщении. Если аргумент не был передан, то сервер выдаёт информацию о всех сообщениях, находящихся в почтовом ящике. Сообщения, помеченные для удаления не перечисляются.
Возможные ответы:
* +OK scan listing follows
* -ERR no such message
Примеры:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop
Команда:RETR [сообщение]
Аргументы: [сообщение] - номер сообщения
Описание: После положительного ответа сервер передаёт содержание сообщения.
Возможные ответы:
* +OK message follows
* -ERR no such message
Примеры:
C: RETR 1
S: +OK 120 octets
S:
S: .
Команда: DELE [ообщение]
Аргументы: [ообщение] - номер сообщения
Описание: POP3 сервер помечает указанное сообщение как удалённое, но не удалет его, пока сессия не перейдёт в редим UPDATE.
Возможные ответы:
* +OK message deleted
* -ERR no such message
Примеры:
C: DELE 1
S: +OK message 1 deleted
...
C: DELE 2
S: -ERR message 2 already deleted
Команда: NOOP
Аргументы: нет
Описание: POP3 сервер ничего не делает и вседа отвечает полжительно.
Возможные ответы:
* +OK
Примеры:
C: NOOP
S: +OK
Команда: RSET
Аргументы: нет
Описание: Если какие - то сообщения были помечены для удаления, то с них снимается эта метка.
Возможные ответы:
* +OK
Примеры:
C: RSET
S: +OK maildrop has 2 messages (320 octets)
Обновление
Когда клиент передаёт команду QUIT в режиме TRANSACTION, то сессия переходит в режим UPDATE. В этом режиме сервер удаляет все сообщения, помеченные для удаления. После этого TCP соединение закрывается.
Дополнительные POP3 команды
Следующие дополнительные команды дают вам большую свободу при работе с сообщениями: Команда: TOP [сообщение] [n] Аргументы: [сообщение] - номер сообщения [n] - положительное число (обязательный аргумент) Описание: Если ответ сервера положительный, то после него он передаёт заголовки сообщения и указанное кол - во строк из тела сообщения. Возможные ответы: +OK top of message follows -ERR no such message Примеры: C: TOP 1 10 S: +OK S: <здесь POP3 сервер передаёт заголовки первого сообщения и первые 10-ть строк из тела сообщения.> S: . ... C: TOP 100 3 S: -ERR no such message Команда: UIDL [сообщение] Аргументы: [сообщение] - номер сообщения (необязательный аргумент). Описание: Если был указан номер сообщения, то сервер выдаёт уникальный идентификатор для этого сообщения. Если аргумент не был передан, то идентификаторы перечисляются для всех сообщений, кроме помеченных для удаления.
Возможные ответы: +OK unique-id listing follows -ERR no such message
Примеры: C: UIDL S: +OK S: 1 whqtswO00WBw418f9t5JxYwZ S: 2 QhdPYR:00WBw1Ph7x7 S: . ... C: UIDL 2 S: +OK 2 QhdPYR:00WBw1Ph7x7 ... C: UIDL 3 S: -ERR no such message, only 2 messages in maildrop
Создать гиперссылку в Delphi довольно просто. На простом примере разберемся с созданием ссылки в Delphi, а затем оформим все в виде компонента.
Алгоритм создания такой: ставим на форму метку (TLabel), приводим ее внешний вид к привычному нам виду гиперссылки в нашем браузере и пишем обработчик события OnClick.
А чтобы можно было постоянно использовать гиперссылку в программах, мы создадим компонент. Начнем с того, что поставим на форму нашего проекта метку (TLabel), пусть ее имя останется Label1. Теперь мы напишем обработчик события OnClick, для нее:
Теперь поясню что мы здесь написали. Функция ShellExecute предназначена для открытия или печати файла, как исполняемого, так и документа. Первый параметр - это handle родительского окна, второй параметр - строка, указывает, что надо сделать с файлом, третий параметр содержит имя открываемого файла, четвертый параметр указывает дополнительные параметры запуска исполняемого файла, пятый параметр определяет директорию по умолчанию, последний параметр определяет где будет отображен файл после октрытия.
Если Вы уже попробовали запустить приведенный код, то скорее всего у Вас ничего не вышло, потому что функция ShellExecute, находится в модуле ShellAPI, который конечно же надо добавить в секцию uses, кода нашего приложения.
Теперь разберем параметры относительно нашего случая:
handle - это дескриптор главной формы (аналогично Form1.handle)
open - тип действия с файлом. Нам надо его открыть.
http://delphiworld.narod.ru/ - имя файла, который надо открыть. У нас это может быть гиперссылка, содержащая абсолютный URI.
nil - здесь никаких дополнительных параметров открытия файла не должно быть, поэтому nil.
nil - директория по умолчанию нас так же не интересует.
SW_SHOW - активирует окно и отображает его с текущими размерами и положением. Об остальных режимах можно узнать в хелпе (о функции ShellExecute).
Второй и третий параметры функции являются нуль терминированными строками, т.е. строками типа PChar, поэтому для использования в функции имени файла, полученного из OpenDialog1, нужно использовать PChar(OpenDialog1.Filename).
В браузере (при настройках по умолчанию) ссылка меняет цвет в зависимости от своего состояния и действий пользователя, мы тоже сделаем так. Для этого создадим три константы (в них будут определяться цвета), которые надо поместить в раздел Implementation:
Теперь в обработчике события формы OnCreate нужно написать:
В обработчике события метки OnMouseDown мы напишем:
А в обработчике события OnMouseUp нашей метки напишем:
Для придания полной реалистичности нашей ссылке, нужно установить свойство метки Cursor в crHandPoint. При наведении на ссылку указатель будет иметь вид привычной нам кисти руки с вытянутым указательным пальцем и ссылка будет подчеркнутой.
Ну вот и разобрались, а теперь напишем компонент. Там все предельно просто и понятно, поэтому объяснения напишу только в виде комментариев в коде.
В качестве родительского класса (Ancestor Type) мы конечно же должны выбрать TLabel. Привожу полный код модуля компонента Link класса Tlink (текст модуля надо сохранить в файле Link.pas):
Вот мы и разобрались с созданием гиперссылок в Delphi, как оказалось все очень просто.
Настройки по умолчанию в Кореле не очень удобны. В любом графическом редакторе всегда хочется иметь как можно больше рабочего пространства. Настройки по умолчанию хороши лишь для изучения редактора, так как все руководства, справка и книги написаны под них. Когда же всё изучено и опробовано, можно настроить интерфейс «под себя». А некоторые опции просто необходимо скорректировать для комфортной работы.
Настраиваем сами Corel Draw.
Настройки по умолчанию в Кореле не очень удобны. В любом графическом редакторе всегда хочется иметь как можно больше рабочего пространства. Настройки по умолчанию хороши лишь для изучения редактора, так как все руководства, справка и книги написаны под них. Когда же всё изучено и опробовано, можно настроить интерфейс «под себя». А некоторые опции просто необходимо скорректировать для комфортной работы.
Для настройки интерфейса обычно используют меню Customization. Но в этой статье часто будет использоваться ещё один способ. Заключается он в том, что элементы интерфейса можно перетаскивать, зажав клавишу Alt, если при перетаскивании воспользоваться сочетанием Ctrl+Alt то перемещаемые элементы дублируется. Чтобы просто удалить элемент достаточно кликнуть на нем правой кнопкой мыши и в появившемся контекстном меню выбрать Customize>Toolbar Item>Delete. Сами «бары» перетаскиваются за двойную линию с левого или верхнего края.
Настройка внешняя.
Удаляем всё лишнее.
В верхней части интерфейса находятся Menu Bar (стандартные File, Edit, View и т.д.), Standard toolbar (панель, где находятся пиктограммы New, Open, Save...) и Property Bar (панель свойств, где устанавливаются параметры страницы, единицы измерения и прочие параметры документа). Menu Bar имеет привычное для большинства Windows приложений расположение, поэтому можно оставить его без изменений. Сэкономить место, здесь можно разместив Standard toolbar и Property Bar в один ряд, что станет возможно, если удалять с Standard toolbar. Лишние элементы, начиная, справа это выпадающее меню масштаба (zoom level), которое дублируется при выбранном Zoom Tool`е, затем кнопки «Access the Corel Graphics Community Web site» и «Start Corel applications», кнопки импорта и экспорта заменят легко запоминающиеся сочетания Ctrl+I и Ctrl+E. Всем знакомы такие сочетания как Ctrl+Z и Ctrl+Shift+Z, соответственно кнопкам со стрелочками «Undo» и «Restore» не место в новом интерфейсе. Опять же копирование/вставка – стандартные во всех приложениях Ctrl+C/X/V, да и в контекстном меню они присутствуют, так что тоже можно смело удалять. В общем, что оставить в Standard toolbar`е и оставлять ли его вообще дело индивидуальное, главное поставить его вряд с Property Bar`ом, что расширит рабочую область аж на 32 пиксела. Беспокоится о неправильных действиях и удалении чегото нужного сильно не стоит. Стандартные панели можно вернуть к прежнему виду в меню Tools>Customization>Command Bars, выделив нужную и нажав кнопку Reset. Либо через контекстное меню Customize>[Toolbar Name]>Reset to Default. Сбросить же все настройки на дефолтные если вдруг ваши эксперименты совсем выйдут из под контроля можно стартовав CorelDRAW с зажатой клавишей F8. То что находится внизу называется Status Bar и по умолчанию занимает неоправдано много места, показывая такие ненужные вещи как позиция курсора, доступные команды для инструментов и свойства объектов которые дублируются на панели свойств. Удалив все лишнее можно разместить вряд Object Information, Object Detalis, Fill Color и Outline color таким образом уменьшив размер панели состояния вдвое.
Ну и наконец немного расширить рабочую область можно отключив линейки, двойной клик и в появившемся окне снять галочку Show Rulers, существенный минус это отсутствие возможности вытягивать из них направляющие (Guidelines) и выставлять нулевые координаты в нужное место. Как вариант можно вынести кнопку включения/отключения линеек в какое-нибудь удобное место, находится она в меню Tools>Customization>Commands выпадающем списке View и называется Rulers.
Панель инструментов (Toolbox).
Та часть интерфейса, в которой расположены инструменты (Pick, Zoom, Shape, Bezier Tools и т.д.) интерактивные эффекты (Blend, Transparency, Envelope и т.д.) и прочее необходимое в работе и есть Toolbox или панель инструментов. По умолчанию она расположена неподвижно в крайней левой части окна и все инструменты расположены в один столбик, а некоторые объеденены в группы. Такой порядок не очень удобен опытному пользователю и уж тем более профессионалу или векторному маньяку.
Расположение в два столбика более практично и удобно, с этого и следует начать – перетащить Toolbox за верхний край со стандартного места в свободную область и растянуть до расположения инструментов в два столбца. Теперь руководствуясь собственным опытом и манерой работы нужно выставить инструменты в нужном порядке. Например Shape Tool можно вынести отдельно от группы и расположить рядом с Pick Tool`ом, также с инструментом Hend, а в выпадающих группах подвинуть наиболее используемые инструменты ближе к левому краю.
Чтобы новая панель выглядела аккуратней можно убрать верхнюю часть с названием и крестиком закрытия, для этого нужно кликнуть на панели правой кнопкой мыши, в контекстном меню выбрать Customize>Toolbox Toolbar>Properties... и в появившемся окне снять галочку «Show title when toolbar is floating».
Докеры (Dockers).
Особенностью интерфейса CorelDRAW является то что многие полезные функции и эффекты реализованы в виде докеров – панелей по умолчанию открывающихся справа. Там им самое место, вот только открывать каждый раз нужный докер не очень удобно, располагаются они в разных частях меню, хотя почти все их можно найти в меню Window>Dockers и на многие уже назначены сочетания клавиш. Наиболее удобный выход держать их открытыми, только в свернутом состоянии, так они будут расположены в нужном порядке удобными вкладками и при надобности разворачиваться одним кликом и так же легко сворачиваться. Определившись с наиболее удобным порядком (чтобы чаще используемые были выше) нужно поочередно открыть их через меню Window>Dockers. После этих действий правая часть экрана будет занята набором удобных закладок.
При желании расположить их можно и не привязывая к экрану, перетаскиваются они также как и другие элементы. В «плавающем» состоянии докеры представляют собой отдельные окошки, напоминающие аналогичные в «Адобовских» продуктах, которые так же легко сворачиваются и объединяются в группы.
Палитру цветов так же можно расположить более удобно, горизонтально например или в виде той же плавающей панели, форма и место расположения практически ничем не ограничиваются.
С принципом настройки интерфейса и некоторыми вариантами модификации, думаю, все понятно, она на то и кастомизация чтобы каждый мог изменить рабочее пространство на удобное ему. Теперь о настройках внутренних.
Настройка внутренняя.
Горячие клавиши.
Здесь каждый вправе сам решать что нужнее всего и достойно назначения клавиш.
В меню Tools>Customization>Commands во вкладке Shortcut Keys назначить свое сочетание клавиш можно любой функции. Совет: при установке горячих клавиш включите режим Navigate to conflict on Assign это позволит не допустить повтора уже существующих сочетаний. И ещё один важный совет: многим в Corel`е не хватает аналога функции Hand Tool в Photoshop`е и Illustrator`е, которой можно перемещаться по рабочей области зажав пробел не отрываясь от основных действий и не переключая инструментов. Такая функция присутствует, но по умолчанию не задействована, исправить ситуацию можно назначив горячую клавишу инструменту Pan (можно тот же пробел) который находится в меню Tools>Customization>Commands в выпадающем списке View.
Опции.
Пройдясь по опциям можно настроить некоторые параметры, сделав работу еще более удобной и продуктивной, начнем по порядку: Tools>Options (Ctrl+J)>Workspace>General тут можно установить количество шагов отката (Undo levels) для основных операций (Regular) и операций с растрами (Bitmap effects), примерные значения 50-100 и 5-10 соответственно.
Тут же можно отключить звуки (снять пометку с Enable sounds). Вкладка Display интересна опцией Enable node Tracking знакомой по ранним версиям CorelDraw (напомню: при активном инструменте Pick Tool и наведении на узлы он превращается в Shape Tool, таким образом можно скруглять углы прямоугольников и перемещать узлы не переключаясь на шейпер). Опция удобная и многим привычная, но не всегда востребованная, а лазить каждый раз в опции для ее включения не очень удобно. Альтернатива есть: в уже знакомом меню Tools>Customization>Commands нужно выбрать в выпадающем списке Edit, найти опцию Tracking и вытащить ее в удобное место на рабочей области или назначить ей сочетание клавиш. Теперь активация функции Node Tracking займет считанные секунды.
Далее во вкладке Edit следует снять галочку с опции Edit Auto-center new PowerClip contents, эта опция размещает объект в центре контейнера поверклипа, что нужно очень редко и если уж возникла такая необходимость, решается предварительным выравниванием объектов клавишами «C» (по вертикали) «E» (по горизонтали).
Следующая вкладка обязательная к посещению Memory, тут следует увеличить объем оперативной памяти используемой приложением со стандартных 25% до 50-75% в зависимости от объема доступной памяти.
Во вкладке Text>Quick Correct нужно снять галочку с одной из самых надоедливых функций CorelDRAW «Capitalize first letter of sentence» которая всюду при наборе текста делает первую букву предложения заглавной, что совершенно не требуется в большинстве случаев.
Часто CorelDRAW импортирует файлы в формате EPS в виде растровых объектов либо не импортирует вообще, для корректного импорта необходимо использовать фильтр «EPS, PS, PRN – PostScript», можно конечно выбирать его вручную в диалоговом окне импорта в выпадающем меню Files of type, но проще назначить его фильтром по умолчанию. Для этого в меню Global > Filters в списке List of active filters нужно выделить нужный фильтр и кнопкой Move Up поднять его выше фильтра «EPS - Encapsulated PostScript». Теперь нужный фильтр будет отвечать за импорт *.eps файлов постоянно.
Ну вот пожалуй и все основные и нуждающиеся в корректировке опции. На последок можно отметить некоторые возможности рассчитанные скорей на любителя нежели необходимые в работе. В меню Customization>Commands в выпадающем списке Status Bar можно найти такие функции как Time, которая как ясно из названия показывает время, Memory Allocated, которая проинформирует о занятой открытыми файлами памяти, а также индикатор статуса привязки Snap Status, и еще ряд подобных мелочей. Их можно расположить как например в том же Status Bar так и назначать горячие клавиши, после нажатия которых информация выведется рядом с курсором.
Node Color Coding.
По умолчанию отключенное нововведение CorelDRAW X3 (похоже, не всегда корректно работает), из название понятно – цветовое выделение узлов, т.е. подсвечивает узлы с разными свойствами (cusp, smooth, simmetrical) своим цветом. Кроме того, выделяется «начальный» узел, что в работе с блендами весьма полезно.
Включается через реестр (Пуск>Выполнить...>regedit):
в ветке
HKEY_CURRENT_USER > Software > Corel > CorelDRAW > 13.0 > CorelDRAW > Application Preferences > Base Tool Pref
присваиваем параметру
"NodeColorCoding"
значение "1".
сохраняем с расширением .reg, и запускаем, после подтверждения функция включится.
Как вы видите CorelDRAW крайне гибкий по части настроек и кастомизации. И каждый не поленившийся потратить часок другой на ковыряние опций и настройку интерфейса без сомнения сэкономит уйму рабочего времени впоследствии и превратит стандартный редактор в индивидуально заточенный инструмент.
Сеть всегда объединяет несколько абонентов, каждый из которых имеет право передавать свои пакеты. Но, как уже отмечалось, по одному кабелю одновременно передавать два (или более) пакета нельзя, иначе может возникнуть конфликт (коллизия), который приведет к искажению либо потере обоих пакетов (или всех пакетов, участвующих в конфликте). Значит, надо каким-то образом установить очередность доступа к сети (захвата сети) всеми абонентами, желающими передавать. Это относится, прежде всего, к сетям с топологиями шина и кольцо. Точно так же при топологии звезда необходимо установить очередность передачи пакетов периферийными абонентами, иначе центральный абонент просто не сможет справиться с их обработкой.
В сети обязательно применяется тот или иной метод управления обменом (метод доступа, метод арбитража), разрешающий или предотвращающий конфликты между абонентами. От эффективности работы выбранного метода управления обменом зависит очень многое: скорость обмена информацией между компьютерами, нагрузочная способность сети (способность работать с различными интенсивностями обмена), время реакции сети на внешние события и т.д. Метод управления – это один из важнейших параметров сети.
Тип метода управления обменом во многом определяется особенностями топологии сети. Но в то же время он не привязан жестко к топологии, как нередко принято считать.
Методы управления обменом в локальных сетях делятся на две группы:
* Централизованные методы, в которых все управление обменом сосредоточено в одном месте. Недостатки таких методов: неустойчивость к отказам центра, малая гибкость управления (центр обычно не может оперативно реагировать на все события в сети). Достоинство централизованных методов – отсутствие конфликтов, так как центр всегда предоставляет право на передачу только одному абоненту, и ему не с кем конфликтовать.
* Децентрализованные методы, в которых отсутствует центр управления. Всеми вопросами управления, в том числе предотвращением, обнаружением и разрешением конфликтов, занимаются все абоненты сети. Главные достоинства децентрализованных методов: высокая устойчивость к отказам и большая гибкость. Однако в данном случае возможны конфликты, которые надо разрешать.
Существует и другое деление методов управления обменом, относящееся, главным образом, к децентрализованным методам:
* Детерминированные методы определяют четкие правила, по которым чередуются захватывающие сеть абоненты. Абоненты имеют определенную систему приоритетов, причем приоритеты эти различны для всех абонентов. При этом, как правило, конфликты полностью исключены (или маловероятны), но некоторые абоненты могут дожидаться своей очереди на передачу слишком долго. К детерминированным методам относится, например, маркерный доступ (сети Token-Ring, FDDI), при котором право передачи передается по эстафете от абонента к абоненту.
* Случайные методы подразумевают случайное чередование передающих абонентов. При этом возможность конфликтов подразумевается, но предлагаются способы их разрешения. Случайные методы значительно хуже (по сравнению с детерминированными) работают при больших информационных потоках в сети (при большом трафике сети) и не гарантируют абоненту величину времени доступа. В то же время они обычно более устойчивы к отказам сетевого оборудования и более эффективно используют сеть при малой интенсивности обмена. Пример случайного метода – CSMA/CD (сеть Ethernet).
Для трех основных топологий характерны три наиболее типичных метода управления обменом.
Управление обменом в сети с топологией звезда
Для топологии звезда лучше всего подходит централизованный метод управления. Это связано с тем, что все информационные потоки проходят через центр, и именно этому центру логично доверить управление обменом в сети. Причем не так важно, что находится в центре звезды: компьютер (центральный абонент), как на рис. 1.6, или же специальный концентратор, управляющий обменом, но сам не участвующий в нем. В данном случае речь идет уже не о пассивной звезде (рис. 1.11), а о некой промежуточной ситуации, когда центр не является полноценным абонентом, но управляет обменом. Это, к примеру, реализовано в сети 100VG-AnyLAN.
Самый простейший централизованный метод состоит в следующем.
Периферийные абоненты, желающие передать свой пакет (или, как еще говорят, имеющие заявки на передачу), посылают центру свои запросы (управляющие пакеты или специальные сигналы). Центр же предоставляет им право передачи пакета в порядке очередности, например, по их физическому расположению в звезде по часовой стрелке. После окончания передачи пакета каким-то абонентом право передавать получит следующий по порядку (по часовой стрелке) абонент, имеющий заявку на передачу (рис. 4.8). Например, если передает второй абонент, то после него имеет право на передачу третий. Если же третьему абоненту не надо передавать, то право на передачу переходит к четвертому и т.д.
Централизованный метод управления обменом в сети с топологией звезда
Рис. 4.8. Централизованный метод управления обменом в сети с топологией звезда
В этом случае говорят, что абоненты имеют географические приоритеты (по их физическому расположению). В каждый конкретный момент наивысшим приоритетом обладает следующий по порядку абонент, но в пределах полного цикла опроса ни один из абонентов не имеет никаких преимуществ перед другими. Никому не придется ждать своей очереди слишком долго. Максимальная величина времени доступа для любого абонента в этом случае будет равна суммарному времени передачи пакетов всех абонентов сети кроме данного. Для топологии, показанной на рис. 4.8, она составит четыре длительности пакета. Никаких столкновений пакетов при этом методе в принципе быть не может, так как все решения о доступе принимаются в одном месте.
Рассмотренный метод управления можно назвать методом с пассивным центром, так как центр пассивно прослушивает всех абонентов. Возможен и другой принцип реализации централизованного управления (его можно назвать методом с активным центром).
В этом случае центр посылает запросы о готовности передавать (управляющие пакеты или специальные сигналы) по очереди всем периферийным абонентам. Тот периферийный абонент, который хочет передавать (первый из опрошенных) посылает ответ (или же сразу начинает свою передачу). В дальнейшем центр проводит сеанс обмена именно с ним. После окончания этого сеанса центральный абонент продолжает опрос периферийных абонентов по кругу (как на рис. 4.8). Если желает передавать центральный абонент, он передает вне очереди.
Как в первом, так и во втором случае никаких конфликтов быть не может (решение принимает единый центр, которому не с кем конфликтовать). Если все абоненты активны, и заявки на передачу поступают интенсивно, то все они будут передавать строго по очереди. Но центр должен быть исключительно надежен, иначе будет парализован весь обмен. Механизм управления не слишком гибок, так как центр работает по жестко заданному алгоритму. К тому же скорость управления невысока. Ведь даже в случае, когда передает только один абонент, ему все равно приходится ждать после каждого переданного пакета, пока центр опросит всех остальных абонентов.
Как правило, централизованные методы управления применяются в небольших сетях (с числом абонентов не более чем несколько десятков). В случае больших сетей нагрузка по управлению обменом на центр существенно возрастает.
Управление обменом в сети с топологией шина
При топологии шина также возможно централизованное управление. При этом один из абонентов ("центральный") посылает по шине всем остальным ("периферийным") запросы (управляющие пакеты), выясняя, кто из них хочет передать, затем разрешает передачу одному из абонентов. Абонент, получивший право на передачу, по той же шине передает свой информационный пакет тому абоненту, которому хочет. А после окончания передачи передававший абонент все по той же шине сообщает "центру", что он закончил передачу (управляющим пакетом), и "центр" снова начинает опрос (рис. 4.9).
Централизованное управление в сети с топологией шина
Рис. 4.9. Централизованное управление в сети с топологией шина
Преимущества и недостатки такого управления – те же самые, что и в случае централизованно управляемой звезды. Единственное отличие состоит в том, что центр здесь не пересылает информацию от одного абонента к другому, как в топологии активная звезда, а только управляет обменом.
Гораздо чаще в шине используется децентрализованное случайное управление, так как сетевые адаптеры всех абонентов в данном случае одинаковы, и именно этот метод наиболее органично подходит шине. При выборе децентрализованного управления все абоненты имеют равные права доступа к сети, то есть особенности топологии совпадают с особенностями метода управления. Решение о том, когда можно передавать свой пакет, принимается каждым абонентом на месте, исходя только из анализа состояния сети. В данном случае возникает конкуренция между абонентами за захват сети, и, следовательно, возможны конфликты между ними и искажения передаваемой информации из-за наложения пакетов.
Существует множество алгоритмов доступа или, как еще говорят, сценариев доступа, порой очень сложных. Их выбор зависит от скорости передачи в сети, длины шины, загруженности сети (интенсивности обмена или трафика сети), используемого кода передачи.
Иногда для управления доступом к шине применяется дополнительная линия связи, что позволяет упростить аппаратуру контроллеров и методы доступа, но заметно увеличивает стоимость сети за счет удвоения длины кабеля и количества приемопередатчиков. Поэтому данное решение не получило широкого распространения.
Суть всех случайных методов управления обменом довольно проста.
Если сеть свободна (то есть никто не передает своих пакетов), то абонент, желающий передавать, сразу начинает свою передачу. Время доступа в этом случае равно нулю.
Если же в момент возникновения у абонента заявки на передачу сеть занята, то абонент, желающий передавать, ждет освобождения сети. В противном случае исказятся и пропадут оба пакета. После освобождения сети абонент, желающий передавать, начинает свою передачу.
Возникновение конфликтных ситуаций (столкновений пакетов, коллизий), в результате которых передаваемая информация искажается, возможно в двух случаях.
* При одновременном начале передачи двумя или более абонентами, когда сеть свободна (рис. 4.10). Это ситуация довольно редкая, но все-таки вполне возможная.
* При одновременном начале передачи двумя или более абонентами сразу после освобождения сети (рис. 4.11). Это ситуация наиболее типична, так как за время передачи пакета одним абонентом вполне может возникнуть несколько новых заявок на передачу у других абонентов.
Существующие случайные методы управления обменом (арбитража) различаются тем, как они предотвращают возможные конфликты или же разрешают уже возникшие. Ни один конфликт не должен нарушать обмен, все абоненты должны, в конце концов, передать свои пакеты.
В процессе развития локальных сетей было разработано несколько разновидностей случайных методов управления обменом.
Коллизии в случае начала передачи при свободной сети
Рис. 4.10. Коллизии в случае начала передачи при свободной сети
Коллизии в случае начала передачи после освобождения сети
Рис. 4.11. Коллизии в случае начала передачи после освобождения сети
Например, был предложен метод, при котором не все передающие абоненты распознают коллизию, а только те, которые имеют меньшие приоритеты. Абонент с максимальным приоритетом из всех, начавших передачу, закончит передачу своего пакета без ошибок. Остальные, обнаружив коллизию, прекратят свою передачу и будут ждать освобождения сети для новой попытки. Для контроля коллизии каждый передающий абонент производит побитное сравнение передаваемой им в сеть информации и данных, присутствующих в сети. Побеждает тот абонент, заголовок пакета которого дольше других не искажается от коллизии. Этот метод, называемый децентрализованным кодовым приоритетным методом, отличается низким быстродействием и сложностью реализации.
При другом методе управления обменом каждый абонент начинает свою передачу после освобождения сети не сразу, а, выдержав свою, строго индивидуальную задержку, что предотвращает коллизии после освобождения сети и тем самым сводит к минимуму общее количество коллизий. Максимальным приоритетом в этом случае будет обладать абонент с минимальной задержкой. Столкновения пакетов возможны только тогда, когда два и более абонентов захотели передавать одновременно при свободной сети. Этот метод, называемый децентрализованным временным приоритетным методом, хорошо работает только в небольших сетях, так как каждому абоненту нужно обеспечить свою индивидуальную задержку.
В обоих случаях имеется система приоритетов, все же данные методы относятся к случайным, так как исход конкуренции невозможно предсказать. Случайные приоритетные методы ставят абонентов в неравные условия при большой интенсивности обмена по сети, так как высокоприоритетные абоненты могут надолго заблокировать сеть для низкоприоритетных абонентов.
[pagebreak]
Чаще всего система приоритетов в методе управления обменом в шине отсутствует полностью. Именно так работает наиболее распространенный стандартный метод управления обменом CSMA/CD (Carrier Sense Multiple Access with Collision Detection – множественный доступ с контролем несущей и обнаружением коллизий), используемый в сети Ethernet. Его главное достоинство в том, что все абоненты полностью равноправны, и ни один из них не может надолго заблокировать обмен другому (как в случае наличия приоритетов). В этом методе коллизии не предотвращаются, а разрешаются.
Суть метода состоит в том, что абонент начинает передавать сразу, как только он выяснит, что сеть свободна. Если возникают коллизии, то они обнаруживаются всеми передающими абонентами. После чего все абоненты прекращают свою передачу и возобновляют попытку начать новую передачу пакета через временной интервал, длительность которого выбирается случайным образом. Поэтому повторные коллизии маловероятны.
Еще один распространенный метод случайного доступа – CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance – множественный доступ с контролем несущей и избежанием коллизий) применяющийся, например, в сети Apple LocalTalk. Абонент, желающий передавать и обнаруживший освобождение сети, передает сначала короткий управляющий пакет запроса на передачу. Затем он заданное время ждет ответного короткого управляющего пакета подтверждения запроса от абонента-приемника. Если ответа нет, передача откладывается. Если ответ получен, передается пакет. Коллизии полностью не устраняются, но в основном сталкиваются управляющие пакеты. Столкновения информационных пакетов выявляются на более высоких уровнях протокола.
Подобные методы будут хорошо работать только при не слишком большой интенсивности обмена по сети. Считается, что приемлемое качество связи обеспечивается при нагрузке не выше 30—40% (то есть когда сеть занята передачей информации примерно на 30—40% всего времени). При большей нагрузке повторные столкновения учащаются настолько, что наступает так называемый коллапс или крах сети, представляющий собой резкое падение ее производительности.
Недостаток всех случайных методов состоит еще и в том, что они не гарантируют величину времени доступа к сети, которая зависит не только от выбора задержки между попытками передачи, но и от общей загруженности сети. Поэтому, например, в сетях, выполняющих задачи управления оборудованием (на производстве, в научных лабораториях), где требуется быстрая реакция на внешние события, сети со случайными методами управления используются довольно редко.
При любом случайном методе управления обменом, использующем детектирование коллизии (в частности, при CSMA/CD), возникает вопрос о том, какой должна быть минимальная длительность пакета, чтобы коллизию обнаружили все начавшие передавать абоненты. Ведь сигнал по любой физической среде распространяется не мгновенно, и при больших размерах сети (диаметре сети) задержка распространения может составлять десятки и сотни микросекунд. Кроме того, информацию об одновременно происходящих событиях разные абоненты получают не в одно время. С тем чтобы рассчитать минимальную длительность пакета, следует обратиться к рис. 4.12.
Пусть L – полная длина сети, V – скорость распространения сигнала в используемом кабеле. Допустим, абонент 1 закончил свою передачу, а абоненты 2 и 3 захотели передавать во время передачи абонента 1 и ждали освобождения сети.
После освобождения сети абонент 2 начнет передавать сразу же, так как он расположен рядом с абонентом 1. Абонент 3 после освобождения сети узнает об этом событии и начнет свою передачу через временной интервал прохождения сигнала по всей длине сети, то есть через время L/V. При этом пакет от абонента 3 дойдет до абонента 2 еще через временной интервал L/V после начала передачи абонентом 3 (обратный путь сигнала). К этому моменту передача пакета абонентом 2 не должна закончиться, иначе абонент 2 так и не узнает о столкновении пакетов (о коллизии), в результате чего будет передан неправильный пакет.
Получается, что минимально допустимая длительность пакета в сети должна составлять 2L/V, то есть равняться удвоенному времени распространения сигнала по полной длине сети (или по пути наибольшей длины в сети). Это время называется двойным или круговым временем задержки сигнала в сети или PDV (Path Delay Value). Этот же временной интервал можно рассматривать как универсальную меру одновременности любых событий в сети.
Стандартом на сеть задается как раз величина PDV, определяющая минимальную длину пакета, и из нее уже рассчитывается допустимая длина сети. Дело в том, что скорость распространения сигнала в сети для разных кабелей отличается. Кроме того, надо еще учитывать задержки сигнала в различных сетевых устройствах. Расчетам допустимых конфигураций сети Ethernet посвящена глава 10.
Отдельно следует остановиться на том, как сетевые адаптеры распознают коллизию в кабеле шины, то есть столкновение пакетов. Ведь простое побитное сравнение передаваемой абонентом информации с той, которая реально присутствует в сети, возможно только в случае самого простого кода NRZ, используемого довольно редко. При применении манчестерского кода, который обычно подразумевается в случае метода управления обменом CSMA/CD, требуется принципиально другой подход.
Как уже отмечалось, сигнал в манчестерском коде всегда имеет постоянную составляющую, равную половине размаха сигнала (если один из двух уровней сигнала нулевой). Однако в случае столкновения двух и более пакетов (при коллизии) это правило выполняться не будет. Постоянная составляющая суммарного сигнала в сети будет обязательно больше или меньше половины размаха (рис. 4.13). Ведь пакеты всегда отличаются друг от друга и к тому же сдвинуты друг относительно друга во времени. Именно по выходу уровня постоянной составляющей за установленные пределы и определяет каждый сетевой адаптер наличие коллизии в сети.
Определение факта коллизии в шине при использовании манчестерского кода
Рис. 4.13. Определение факта коллизии в шине при использовании манчестерского кода
Задача обнаружения коллизии существенно упрощается, если используется не истинная шина, а равноценная ей пассивная звезда (рис. 4.14).
Обнаружение коллизии в сети пассивная звезда
Рис. 4.14. Обнаружение коллизии в сети пассивная звезда
При этом каждый абонент соединяется с центральным концентратором, как правило, двумя кабелями, каждый из которых передает информацию в своем направлении. Во время передачи своего пакета абоненту достаточно всего лишь контролировать, не приходит ли ему в данный момент по встречному кабелю (приемному) другой пакет. Если встречный пакет приходит, то детектируется коллизия. Точно так же обнаруживает коллизии и концентратор.
Управление обменом в сети с топологией кольцо
Кольцевая топология имеет свои особенности при выборе метода управления обменом. В этом случае важно то, что любой пакет, посланный по кольцу, последовательно пройдя всех абонентов, через некоторое время возвратится в ту же точку, к тому же абоненту, который его передавал (так как топология замкнутая). Здесь нет одновременного распространения сигнала в две стороны, как в топологии шина. Как уже отмечалось, сети с топологией кольцо бывают однонаправленными и двунаправленными. Наиболее распространены однонаправленные.
В сети с топологией кольцо можно использовать различные централизованные методы управления (как в звезде), а также методы случайного доступа (как в шине), но чаще выбирают все-таки специфические методы управления, в наибольшей степени соответствующие особенностям кольца.
Самые популярные методы управления в кольцевых сетях маркерные (эстафетные), те, которые используют маркер (эстафету) – небольшой управляющий пакет специального вида. Именно эстафетная передача маркера по кольцу позволяет передавать право на захват сети от одного абонента к другому. Маркерные методы относятся к децентрализованным и детерминированным методам управления обменом в сети. В них нет явно выраженного центра, но существует четкая система приоритетов, и потому не бывает конфликтов.
Работа маркерного метода управления в сети с топологией кольцо представлена на рис. 4.15.
Рис. 4.15. Маркерный метод управления обменом (СМ—свободный маркер, ЗМ— занятый маркер, МП— занятый маркер с подтверждением, ПД—пакет данных)
По кольцу непрерывно ходит специальный управляющий пакет минимальной длины, маркер, предоставляющий абонентам право передавать свой пакет. Алгоритм действий абонентов:
1. Абонент 1, желающий передать свой пакет, должен дождаться прихода к нему свободного маркера. Затем он присоединяет к маркеру свой пакет, помечает маркер как занятый и отправляет эту посылку следующему по кольцу абоненту.
2. Все остальные абоненты (2, 3, 4), получив маркер с присоединенным пакетом, проверяют, им ли адресован пакет. Если пакет адресован не им, то они передают полученную посылку (маркер + пакет) дальше по кольцу.
3. Если какой-то абонент (в данном случае это абонент 2) распознает пакет как адресованный ему, то он его принимает, устанавливает в маркере бит подтверждения приема и передает посылку (маркер + пакет) дальше по кольцу.
4. Передававший абонент 1 получает свою посылку, прошедшую по всему кольцу, обратно, помечает маркер как свободный, удаляет из сети свой пакет и посылает свободный маркер дальше по кольцу. Абонент, желающий передавать, ждет этого маркера, и все повторяется снова.
Приоритет при данном методе управления получается географический, то есть право передачи после освобождения сети переходит к следующему по направлению кольца абоненту от последнего передававшего абонента. Но эта система приоритетов работает только при большой интенсивности обмена. При малой интенсивности обмена все абоненты равноправны, и время доступа к сети каждого из них определяется только положением маркера в момент возникновения заявки на передачу.
В чем-то рассматриваемый метод похож на метод опроса (централизованный), хотя явно выделенного центра здесь не существует. Однако некий центр обычно все-таки присутствует. Один из абонентов (или специальное устройство) должен следить, чтобы маркер не потерялся в процессе прохождения по кольцу (например, из-за действия помех или сбоя в работе какого-то абонента, а также из-за подключения и отключения абонентов). В противном случае механизм доступа работать не будет. Следовательно, надежность управления в данном случае снижается (выход центра из строя приводит к полной дезорганизации обмена). Существуют специальные средства для повышения надежности и восстановления центра контроля маркера.
Основное преимущество маркерного метода перед CSMA/CD состоит в гарантированной величине времени доступа. Его максимальная величина, как и при централизованном методе, составит (N-1)• tпк, где N – полное число абонентов в сети, tпк – время прохождения пакета по кольцу. Вообще, маркерный метод управления обменом при большой интенсивности обмена в сети (загруженность более 30—40%) гораздо эффективнее случайных методов. Он позволяет сети работать с большей нагрузкой, которая теоретически может даже приближаться к 100%.
Метод маркерного доступа используется не только в кольце (например, в сети IBM Token Ring или FDDI), но и в шине (в частности, сеть Arcnet-BUS), а также в пассивной звезде (к примеру, сеть Arcnet-STAR). В этих случаях реализуется не физическое, а логическое кольцо, то есть все абоненты последовательно передают друг другу маркер, и эта цепочка передачи маркеров замкнута в кольцо (рис. 4.16). При этом совмещаются достоинства физической топологии шина и маркерного метода управления.
Применение маркерного метода управления в шине
Рис. 4.16. Применение маркерного метода управления в шине
Информация в локальных сетях, как правило, передается отдельными порциями, кусками, называемыми в различных источниках пакетами (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. Многоуровневая система вложения пакетов
Каждый следующий вкладываемый пакет может содержать собственную служебную информацию, располагающуюся как до данных (заголовок), так и после них (трейлер), причем ее назначение может быть различным. Безусловно, доля вспомогательной информации в пакетах при этом возрастает с каждым следующим уровнем, что снижает эффективную скорость передачи данных. Для увеличения этой скорости предпочтительнее, чтобы протоколы обмена были проще, и уровней этих протоколов было меньше. Иначе никакая скорость передачи битов не поможет, и быстрая сеть может передавать файл дольше, чем медленная сеть, которая пользуется более простым протоколом.
Обратный процесс последовательной распаковки данных приемником называется декапсуляцией пакетов.
Информация в кабельных локальных сетях передается в закодированном виде, то есть каждому биту передаваемой информации соответствует свой набор уровней электрических сигналов в сетевом кабеле. Модуляция высокочастотных сигналов применяется в основном в бескабельных сетях, в радиоканалах. В кабельных сетях передача идет без модуляции или, как еще говорят, в основной полосе частот.
Правильный выбор кода позволяет повысить достоверность передачи информации, увеличить скорость передачи или снизить требования к выбору кабеля. Например, при разных кодах предельная скорость передачи по одному и тому же кабелю может отличаться в два раза. От выбранного кода напрямую зависит также сложность сетевой аппаратуры (узлы кодирования и декодирования кода). Код должен в идеале обеспечивать хорошую синхронизацию приема, низкий уровень ошибок, работу с любой длиной передаваемых информационных последовательностей.
Некоторые коды, используемые в локальных сетях, показаны на рис. 3.8. Далее будут рассмотрены их преимущества и недостатки.
Наиболее распространенные коды передачи информации
Рис. 3.8. Наиболее распространенные коды передачи информации
Код NRZ
Код NRZ (Non Return to Zero – без возврата к нулю) – это простейший код, представляющий собой обычный цифровой сигнал. Логическому нулю соответствует высокий уровень напряжения в кабеле, логической единице – низкий уровень напряжения (или наоборот, что не принципиально). Уровни могут быть разной полярности (положительной и отрицательной) или же одной полярности (положительной или отрицательной). В течение битового интервала (bit time, BT), то есть времени передачи одного бита никаких изменений уровня сигнала в кабеле не происходит.
К несомненным достоинствам кода NRZ относятся его довольно простая реализация (исходный сигнал не надо ни специально кодировать на передающем конце, ни декодировать на приемном конце), а также минимальная среди других кодов пропускная способность линии связи, требуемая при данной скорости передачи. Ведь наиболее частое изменение сигнала в сети будет при непрерывном чередовании единиц и нулей, то есть при последовательности 1010101010..., поэтому при скорости передачи, равной 10 Мбит/с (длительность одного бита равна 100 нс) частота изменения сигнала и соответственно требуемая пропускная способность линии составит 1 / 200нс = 5 МГц (рис. 3.9).
Скорость передачи и требуемая пропускная способность при коде NRZ
Рис. 3.9. Скорость передачи и требуемая пропускная способность при коде NRZ
Передача в коде NRZ с синхросигналом
Рис. 3.10. Передача в коде NRZ с синхросигналом
Самый большой недостаток кода NRZ – это возможность потери синхронизации приемником во время приема слишком длинных блоков (пакетов) информации. Приемник может привязывать момент начала приема только к первому (стартовому) биту пакета, а в течение приема пакета он вынужден пользоваться только внутренним тактовым генератором (внутренними часами). Например, если передается последовательность нулей или последовательность единиц, то приемник может определить, где проходят границы битовых интервалов, только по внутренним часам. И если часы приемника расходятся с часами передатчика, то временной сдвиг к концу приема пакета может превысить длительность одного или даже нескольких бит. В результате произойдет потеря переданных данных. Так, при длине пакета в 10000 бит допустимое расхождение часов составит не более 0,01% даже при идеальной передаче формы сигнала по кабелю.
Во избежание потери синхронизации, можно было бы ввести вторую линию связи для синхросигнала (рис. 3.10). Но при этом требуемое количество кабеля, число приемников и передатчиков увеличивается в два раза. При большой длине сети и значительном количестве абонентов это невыгодно.
В связи с этим код NRZ используется только для передачи короткими пакетами (обычно до 1 Кбита).
Большой недостаток кода NRZ состоит еще и в том, что он может обеспечить обмен сообщениями (последовательностями, пакетами) только фиксированной, заранее обговоренной длины. Дело в том, что по принимаемой информации приемник не может определить, идет ли еще передача или уже закончилась. Для синхронизации начала приема пакета используется стартовый служебный бит, чей уровень отличается от пассивного состояния линии связи (например, пассивное состояние линии при отсутствии передачи – 0, стартовый бит – 1). Заканчивается прием после отсчета приемником заданного количества бит последовательности (рис. 3.11).
Определение окончания последовательности при коде NRZ
Рис. 3.11. Определение окончания последовательности при коде NRZ
Наиболее известное применение кода NRZ – это стандарт RS232-C, последовательный порт персонального компьютера. Передача информации в нем ведется байтами (8 бит), сопровождаемыми стартовым и стоповым битами.
Три остальных кода (RZ, манчестерский код, бифазный код) принципиально отличаются от NRZ тем, что сигнал имеет дополнительные переходы (фронты) в пределах битового интервала. Это сделано для того, чтобы приемник мог подстраивать свои часы под принимаемый сигнал на каждом битовом интервале. Отслеживая фронты сигналов, приемник может точно синхронизовать прием каждого бита. В результате небольшие расхождения часов приемника и передатчика уже не имеют значения. Приемник может надежно принимать последовательности любой длины. Такие коды называются самосинхронизирующимися. Можно считать, что самосинхронизирующиеся коды несут в себе синхросигнал.
Событие - это какое-либо действие, осуществляемое пользователем либо браузером. Например, когда мы щелкаем (кликаем) на ссылке - осуществляется событие, его перехватывает специальный обработчик и перенаправляет нас на нужную страницу; при наведении курсора (указателя мыши) на ссылку в строке состояния (обычно находится в нижней части окна браузера) отображается адрес, так как обработчик "наведения курсора на объект (в данном случае на ссылку)" помещает туда этот адрес и так далее...
а). onmouseout и onmouseover
Для начала наведем курсор на кнопку "Сброс" или "Отправить" и обратим внимание на строку состояния. Вы должны увидеть там надпись с объяснением значения кнопки. Теперь отведите курсор и строка состояния очистится.
Содержимое строки состояния хранится в переменной window.status. Переменная это некоторый объект (можно представить себе ящик), значение которого (содержимое которого) можно изменять. Изменение значения осуществляется операцией присваивания (=), а выглядит она следующим образом:
имя_переменной = "значение"; (какие использовать кавычки: одинарные или двойные значения не имеет)
Поэтому для того, чтобы изменить надпись в строке состояния, нам нужно присвоить переменной window.status нужное нам значение (подсказку к кнопке), а когда курсор будет убран - присвоить пустую строку("").
Вся задача сводится к тому, чтобы определить когда пользователь наводит курсор на кнопку, а когда убирает его. Для этого нужно "сказать" обработчикам этих событий выполнить нужное нам действие. Обработчик события "наведение курсора" - onmouseover, а "отведение курсора" - onmouseout.
Очень многие тэги имеют атрибуты, начинающиеся с on (onclick, onmouseout, onfocus и т. д.). Значение этих атрибутов и есть, задача которую необходимо выполнить соответствующему обработчику. То есть для обработчика onmouseout есть атрибут onmouseout, для onmouseover - onmouseover. И в итоге мы получаем следующее определение кнопок:
Как Вы видите, атрибут onmouseover имеет в качестве значения JavaScript-код: window.status='Щелкните для отправки данных', как только курсор достигает кнопки, обработчик события mouseover - onmouseover, смотрит, что хранится в атрибуте onmouseover и выполняет необходимое действие(присвоение значения переменной window.status). Аналогично действует и обработчик события onmouseout: как только курсор уводиться от кнопки (то есть выполняется событие mouseout), то обработчик события - onmouseout выполняет код, содержащийся в атрибуте onmouseout.
То же самое и со второй кнопкой.
б). <a href="Java Scriptfunction()">Function</a>
Теперь щелкните на ссылке и откроется окошко с подсказкой. Но заметьте, что окно небольших размеров и у него нет панели инструментов - такого силами html не сделаешь! В данном примере мы имеем окно размером 300x200, без панелей инструментов, содержащее документ help.html.
Для того чтобы создать такое окошко существует следующий JavaScript-код:
где:
1. helpWindow - это имя переменной (как window.status, только в данном случае имя выбирается произвольно). Эта переменная нужна для последующей работы с окном (например, закрыть его нестандартным способом - с помощью JavaScript-сценария).
- Зачем? Не проще ли указывать просто имя открывающейся страницы, например help.html?
- А если у нас две копии одной и той же страницы? Или две страницы с одинаковым именем(например, в разных папках)? Вот для того, чтобы не перепутать страницы и свободно работать именно с тем окном с которым предполагаешь и сделанно, так чтобы "окно" присваивалось переменной, так как имя переменной можно выбрать любое.
2. window.open(что-то) - это функция. Функции выполняют определенную задачу, в данном случае window.open() открывает новое окно.
3. help.html - это страница, которую нужно открыть.
4. "" - В кавычках должно быть имя окна, но оно нам не пригодится, поэтому там нулевая строка. В следующих кавычках указываются "параметры открываемого окна": оно не должно содержать панели инструментов (toolbar=0) и должно быть шириной 300 пикселей, а высотой - 200 (width=300,height=200, соответственно).
Теперь все, что нужно это по событию "щелчка" выполнить этот код, однако есть два "но". Во-первых строка очень длинная, чтобы присвоить ее какому-либо атрибуту - будет некрасиво смотреться, да и вызывать неудобства при чтении кода страницы. Во-вторых, первоначальное предназначение ссылки - это переход на другую страницу, но нам переходить никуда не нужно, нам нужно выполнить вместо этого JavaScript-код.
Первое решается написанием функции. Как я уже говорил функция выполняет некоторую задача, причем для использования функции достаточно указать ее имя. Можно не только использовать предопределенные(функции, которые имеется в языке и без нас), но и писать их самому. Обычно функции определяются(пишутся) в разделе HEAD документа, в котором используются:
"function" значит, что дальше будет написана наша функция; help() - это имя функции (оно будет указываться вместо тела функции (между { и })).
Вторая проблема решается тоже довольно просто. Адрес страницы указывается в атрибуте href, а нам надо выполнить JavaScript код вместо перехода по ссылке:
"Java Script" означает, что дальше должен идти JavaScript-код, и что он должен выполняться вместо стандартного перехода по ссылке. В данном случае наш JavaScript-код - это созданная нами функция help().
в). onclick
Нам не остается ничего более, как закрыть окно со справкой. Для этого воспользуемся кнопкой "Закрыть". Но нас интересует то, как работает эта кнопка, а имеет она следующий вид:
Дабы закрыть окно мы сделали щелчок(Click) на кнопке "Закрыть", а щелчок это нажатие и отпускание кнопки мыши, причем и то и другое должно быть произведено на одном и том же элементе (например, на кнопке). Кликая, на кнопке мы активируем обработчик события onClick, который выполняет для нас JavaScript-код, прописанный в атрибуте onclick нашей кнопки. Помните мы открывали окно? Мы писали window.open(), а здесь тоже самое только window.close(). window - это текущее окно, а close() - закрыть.
Это одно из наиболее частоупотребляемых событий.
г). onfocus и onblur
Ну что ж будем ближе подбираться к вводу требуемой от нас информации.
Как я уже говорил: элемент получает фокус когда на нем происходит нажатие кнопки мыши, или на него осуществляется переход посредством клавиши табуляции (Tab), а теряет, когда фокус получает другой элемент. Наше поле для ввода получит фокус тогда, когда пользователь решиться ввести информацию. При этом было бы удобно, чтобы текст с подсказкой ("Введите Ваше имя") автоматически выделялся и посетитель мог его удалить одним нажатием на del, а не удалять по одному символу, или выделять текст вручную. Удобство пользователя свято. Итак, для этого мы воспользуемся событием focus. Для выделения текста используется метод select(). То есть атрибутом к полю надо прописать: onfocus="this.select();", this обозначает, что выделение должно происходить именно в этом текстовом поле (а можно прописать путь и к другому, но это не целесообразно).
А теперь попробуйте ничего не изменяя (или все удалив) убрать фокус (например, щелкнув в любом месте окна, или нажав Tab). Это событие blur, я прописал в нем выполнение функции: onblur="check();". Сама же функция имеет следующий вид (в разделе head страницы с формой между <script> и </script>):
document.forms[0].name.value - это то, что введено в текстовое поле. document - это текущий документ, forms[0] - первая форма на нашей страницы (отсчет с нуля), name = имя поля (задается атрибутом name (<input name="name">)), а value это и есть нужное нам значение (то, что введенно в текстовое поле, к которому м ы и написали путь). Введенное в поле мы присваиваем переменной val (var значит, что дальше идет имя переменной), чтобы в дальнейшем каждый раз не писать весь путь целиком.
Следующее это оператор if(если). Он выглядит следующим образом:
Мы сравниваем содержание переменной val с пустой строкой ('') и с начальной строкой ('Введите Ваше имя'). Обратите внимание, что сравнение не как в математике(с одним =), а сравниваются двума ==. || - или. Функция alert выводит окно с ошибкой (то, что в скобках - это текст ошибки). То есть:
И на всякий случай приведу целиком строку с кодом поля input:
д). onreset и onsubmit
Допустим, что пользователь заполнил форму неправильно, и он хочет очистить все поля формы одновременно: для этого он воспользуется стандартной кнопкой reset. Но что если пользователь щелкнет на ней по случайности (рука дрогнет, или в суете спутает с кнопкой submit), а форма была огромная, и он долго мучился ее заполнять..., ему будет грустно, и еще он будет долго материться. Поэтому хорошо бы у него дополнительно спросить: действительно ли он хочет очистить форму.
Вообще событие reset обрабатывается до очистки формы. А чтобы отменить очистку вообще, нам просто напросто надо вернуть обработчику события значение false, то есть прописать в соответствующем атрибуте: "return false;", а чтобы продолжить очистку: "return true;". А теперь вспомним функцию, которая выдает вопрос пользователю на подтверждение чего-либо, эта функция: "confirm('Вопрос?');". При нажатии "Ok", эта функция заменяется на true, а при нажатии "Cancel" на false. То есть все что от нас требуется, это прописать в теге <form> атрибут: onreset="return confirm('Вы действительно хотите сбросить форму?');". Тогда при нажатии "Ok" там на самом деле будет "return true;", и форма будет очищена, а если "Cancel", то "return false;" и очистка формы будет отменена.
Подобным образом действует событие submit, которое возникает при попытке отправить форму. Поскольку в нашем случае форму отправлять никуда не надо, то у меня просто написано: onsubmit="return false;". И сколько бы Вы не щелкали ничего не изменится (разве что Вы JavaScript отключите).
Обычно же обработчик onsubmit используется для верификации формы (то есть проверки на заполнение всех необходимых полей, правильность их заполнения, скажем, проверка по определенному шаблону и т. п.), для этого создается функция, которая выполняет все действия. Функция должна содержать операторы "return true" и "return false", которые позволяют, заменить функцию на true или false, соответственно, в зависимости от результатов проверки (если успешно, то true, если нет false). Но верификация данных это обширная тема, которая не может быть рассмотрена здесь. Один из примеров базовой верификации я привел, когда объяснял событие blur - подобную функцию можно использовать и здесь. Тогда <form> будет содержать атрибут: onsubmit="return function();".
Но не забывайте, что нельзя ограничиваться одной лишь проверкой языком JavaScript, ибо его поддержка может быть отключена у посетителя, и тогда все Ваши труды по защите...
е). onmousedown и onmouseup
Еще одна пара событий не нашла достойного места на странице, но я ее реализовал в виде кнопки "Button". Причем это не обычная html-кнопка, она реализована в виде двух картинок. Исходная кнопка хранится в файле с именем npressed.jpg, а нажатая - pressed.jpg. Чтобы достичь эффекта нажатия кнопки нам необходимо, чтобы при при щелчке на ней(this) значение атрибута src (путь к картинке) тега <img> менялось на pressed.jpg, а при отпускании обратно на npressed.jpg. Нажатие кнопки обрабатывает onmousedown, а отпускание - onmouseup, то есть здесь все просто:
ж). onload, onunload и onabort
Обработчик события onload активируется, когда начинает загружаться графическая часть страницы (все тексты, графика и т.п.). onload является атрибутом тега <body>. Если честно я не вижу сколько бы реального применения этому событию, зато я нашел, что можно сделать с onunload. onunload это тоже атрибут тега <body>. Событие unload происходит когда мы пытаемся покинуть данную страницу (переходим по ссылке на другую, закрываем окно браузера, обновляем страницу и т. д.). Откройте еще раз окошко справки. Допустим, что пользователь прочитал справку, и хочет отправить форму, или уйдет с нашего сайта, но при этом он забыл закрыть это маленькое окошко с подсказкой, мы на выходе закроем его сами. А для этого тег <body> (у начального документа) у нас будет выглядеть следующим образом:
Вы должны бы помнить, что helpWindow это имя нашего окна (ведь именно этой переменной мы присваивали его открытие: helpWindow = window.open("help.html", "", "toolbar=0,width=300,height=200")), а метод close() закрывает это окно. Некоторые нехорошие люди используют это событие, чтобы когда посетители уходили с его страницы, появлялись какие-либо окна, так называемые pop-up.
onabort - атрибут тега <img>. Когда пользователь отменяет загрузку изображения происходит событие abort. Но отмена загрузки изображения может не входить в наши плане. И в качестве предупреждения у нас может быть написано нечто похожее на
ЗАКЛЮЧЕНИЕ
Есть некоторые события о которых я здесь нарочно не упомянул, потому что не нашел им достойного применения, но Вам они возможно пригодятся, поэтому я уделю им немного внимания.
onchange - обработчик события, который активируется, когда Вы изменяете содержимое текстового элемента или текстовой области (<TEXTAREA>) (например, когда Вы вводите или удаляете очередную букву какого-либо текстового поля).
onselect - обработчик события выбора текста. То есть это событие происходит, когда пользователь пытается выделить текст в текстовом элементе или текстовой области.
onerror - обработчик события error, которое возникает при ошибке загрузки документа или изображения (то есть onerror это атрибут тегов <body> и <img>). Оно возникает при синтаксической ошибке JavaScript-кода (но Вы ведь не будете специально делать в нем ошибки), либо ошибкой времени выполнения (например, если Ваш скрипт выполняет какие-либо вычисления и у Вас по ошибке получится так, что некое число будет делиться на ноль, а это недопустимо - это и есть одна из ошибок времени выполнения).
Так же не забывайте, что я привел лишь по одному примеру из десятков возможных на каждое событие. Здесь главное Ваша фантазия и навыки. Например, события mouseout, mouseover, mouseup, mousedown часто используются для создания выпадающих меню и других визуальных эффектов, но это весьма трудный материал, который требует более глубоких знаний, причем не одного JavaScript.
Прародителем сети интернет была сеть ARPANET. Первоначально её разработка финансировалась Управлением перспективного планирования (Advanced Research Projects Agency, или ARPA). Проект стартовал осенью 1968 года и уже в сентябре 1969 года в опытную эксплуатацию был запущен первый участок сети ARPANET.
Сеть ARPANET долгое время являлась тестовым полигоном для исследования сетей с коммутацией пакетов. Однако кроме исследовательских, ARPANET служила и чисто практическим целям. Ученые нескольких университетов, а также сотрудники некоторых военных и государственных исследовательских институтов регулярно её использовали для обмена файлами и сообщениями электронной почты, а так же для работы на удалённых компьютерах. В 1975 году управление сетью было выведено из под контроля ARPA и поручено управлению связи Министерства обороны США. Для военных данная сеть представляла большой интерес, так как позволяла сохранять её работоспособность даже при уничтожении её части, например, при ядерном ударе.
В 1983 году Министерство обороны разделило ARPANET на две связанные сети. При этом за сетью ARPANET были сохранены её исследовательские функции, а для военных целей была сформирована новая сеть, которую назвали MILNET. Физически сеть ARPANET состояла приблизительно из 50 миникомпьютеров типа С30 и С300, выпущенных фирмой BBN Corporation. Они назывались узлами коммутации пакетов и были разбросаны по территории материковой части США и Западной Европы. Сеть MILNET состояла приблизительно из 160 узлов, причём 34 из них были расположены в Европе, а 18 в Тихом Океане и в Азиатско-Тихоокеанском регионе. Сами узлы коммутации пакетов нельзя было использовать для решения вычислительных задач общего плана.
Понимая, что в ближайшем будущем очень важным моментом в научных исследованиях будет процесс обмена данными, Национальный научный фонд (NFS) в 1987 году основал отделение сетевых и коммуникацинных исследований и инфраструктуры. В его задачи входило обеспеченье современными сетевыми коммуникационными средствами учёных и инженеров США. И хотя отделение фонда NFS финансировало основные исследовательские программы в области сетевых коммуникаций, сферой его основных интересов было расширение Internet.
Сеть NSFNET строилась в несколько этапов и быстро преобретала популярность не только в научно-исследовательских кругах, но и в коммерческой среде. К 1991 году фонд NFS и другие государственные учреждения США поняли, что масштабы Internet вышли далеко за отведённые её на этапе разработки рамки университетской и научной сети. К Internet стало подключаться множество организаций, разбросанных по всему Земному шару. Трафик в магистральном канале NSFNET вырос почти до миллиарда пакетов в день, и его пропускной способности 1.5 Мбит/с на отдельных участках стало уже не хватать. Поэтому правительство США начало проводить политику приватизации и коммерческого использования Internet. Фонд NFS принял решение предать магистральную сеть на попечение закрытой акционерной компании и оплачивать доступ к ней для государственных научных и исследовательских организаций.
Семейство TCP/IP
Познакомившись с историей, давайте подробнее рассмотрим, что собой представляют протоколы TCP/IP. TCP/IP - это семейство сетевых протоколов, ориентированных на совместную работу. В состав семейства входит несколько компонентов:
IP (Internet Protocol - межсетевой протокол) - обеспечивает транспортировку пакетов данных с одного компьютера на другой;
ICMP (Internet Control Message Protocol - протокол управляющих сообщений в сети Internet) - отвечает за различные виды низкоуровневой поддержки протокола IP, включая сообщения об ошибках, вспомогательные маршрутизирующие запросы и подтверждения о получении сообщений;
ARP (Address Resolution Protocol - протокол преобразования адресов) - выполняет трансляцию IP-адресов в аппаратные MAC-адреса;
UDP (User Datagram Protocol - протокол передачи дейтаграмм пользователя) и TCP (Transmission Control Protocol - протокол управления передачей) - обеспечивают доставку данных конкретным приложениям на указанном компьютере. Протокол UDP реализует передачу отдельных сообщений без подтверждения доставки, тогда как TCP гарантирует надёжный полнодуплексный канал связи между процессами на двух разных компьютерах с возможностью управления потоком и контроля ошибок.
Протокол представляет собой набор правил, использующихся для при обмене данными между двумя компьютерами. В нём оговариваются формат блоков сообщений, описывается реакция компьютера на получение определённого типа сообщения и указываются способы обработки ошибок и других необычных ситуаций. И что самое важное, благодаря протоколам, мы можем описать процесс обмена данными между компьютерами, не привязываясь к какой-то определённой комьютерной платформе или сетевому оборудованию конкретного производителя.
Сокрытие низкоуровневых особенностей процесса передачи данных способствует повышению производительности труда разработчиков. Во-первых, поскольку программистам приходится иметь дело с протоколами, относящимися к достаточно высокому уровню абстракции, им не нужно держать в голове (и даже изучать!) технические подробности испольуемого аппаратного обеспечения. Во-вторых, поскольку программы разрабатываются на основе модели, относящейся к высокому уровню абстракции, который не зависит от конкретной архитектуры компьютера или типа сетевого оборудования, в них не нужно вносить никаких изменений при переходе на другой тип оборудования или изменений конфигурации сети.
Замечание Говорить о том, что ARP входит в состав семейства протоколов TCP/IP не совсем корректно. Однако это неотъемлемая часть стека протоколов в сетях Ethernet. Для того чтобы отправить данные по сети, IP-адрес хоста должен быть преобразован в физический адрес машины получателя (уникальный адрес сетевой платы). Протокол ARP как раз и предназначен для такой цели.
Самым фундаментальным протоколом Интернета является протокол IP (от англ. Internet Protocol), обеспечивающий передачу данных между двумя удаленными компьютерами. Протокол IP является достаточно простым, и обеспечивает адресацию в сети. В ранних сетях адреса в сети были уникальные целые цифры, сейчас сеть построена по иерархическому принципу.
Стек протоколов TCP/IP имеет четыре основных уровня, поэтому часто говорят, что TCP/IP — это четырехуровневый стек протоколов. Внизу стека расположен интерфейсный уровень, посредством которого происходит связь с аппаратурой. За ним следует уровень IP, поверх которого построены транспортные протоколы TCP и UDP. На вершине стека находится уровень приложений, таких как ftp, telnet и т. д. Как мы уже говорили, IP — это простой протокол, не требующий установления соединения. При отсылке пакета данных, IP, как и все протоколы без соединения, послав пакет, тут же "забывает" о нем. При приеме пакетов с верхних уровней стека, этот протокол обертывает их в IP-пакет и передает необходимому аппаратному обеспечению для отправки в сеть. Однако именно в такой простоте и заключается основное достоинство протокола IP. Дело в том, что поскольку IP является простым протоколом, он никак не связан со структурой физической среды, по которым передаются данные. Для протокола IP главное, что эта физическая среда в принципе способна к передаче пакетов. Поэтому IP работает как в локальных, так и в глобальных сетях, как в синхронном, так и в асинхронном режиме передачи данных, как в обычных линиях связи, так и беспроводных и т. д. А поскольку протокол IP является фундаментом четырехуровнего сте-ка протоколов, то все семейство протоколов TCP/IP также может функционировать в любой сети с любым режимом передачи пакетов.
На сетевом уровне в семействе протоколов TCP/IP предусмотрено два обширных класса служб, которые используются во всех приложениях.
Служба доставки пакетов, не требующая установки соединения.
Надёжная потоковая транспортная служба.
Различие между службами, требующими установления надёжного соединения и службами, не требующими этого, является одним из самых основных вопросов сетевого программирования. Первое, на что следует обратить внимание, это то, что когда мы говорим об установлении соединения, то имеется в виду не соединение между компьютерами посредством физического носителя, а о способе передачи данных по этому носителю. Основное различие состоит в том, что службы, в которых устанавливается надёжное соединение, сохраняют информацию о состоянии и таким образом отслеживают информацию о передаваемых пакетах. В службах же, не требующих надёжного соединения, пакеты передаются независимо друг от друга.
Данные передаются по сети в форме пакетов, имеющих максимальный размер, определяемый ограничениями канального уровня. Каждый пакет состоит из заголовка и полезного содержимого (сообщения). Заголовок включает сведения о том, откуда прибыл пакет и куда он направляется. Заголовок, кроме того, может содержать контрольную сумму, информацию, характерную для конкретного протокола, и другие инструкции, касающиеся обработки пакета. Полезное содержимое – это данные, подлежащие пересылке.
Имя базового блока передачи данных зависит от уровня протокола. На канальном уровне это кадр или фрейм, в протоколе IP – пакет, а в протоколе TCP – сегмент. Когда пакет передаётся вниз по стеку протоколов, готовясь к отправке, каждый протокол добавляет в него свой собственный заголовок. Законченный пакет одного протокола становится полезным содержимым пакета, генерируемого следующим протоколом.
Определение
Пакеты, которые посылаются протоколом, не требующим соединения, называются дейтаграммами.
Каждая дейтаграмма является уникальной в том смысле, что никак не зависит от других. Как правило, при работе с протоколами без установления соединения, диалог между клиентом и сервером предельно прост: клиент посылает одиночный запрос, а сервер на него отвечает. При этом каждый новый запрос — это новая транзакция, т. е. инициируемые клиентом запросы никак не связаны друг с другом с точки зрения протокола. Протоколы без установления соединения ненадежны в том смысле, что нет никаких гарантий, что отправленный пакет будет доставлен по месту назначения.
Протоколами, требующие установления логического соединения, сохраняют информацию о состоянии, что позволяет обеспечивать надежную доставку пересылаемых данных. Когда говорится о сохранении состояния, имеется ввиду то, что между отправителем и получателем происходит обмен информацией о ходе выполнения передачи данных. К примеру, отправитель, посылая данные, сохраняет информацию о том, какие данные он послал. После этого в течении определенного времени он ожидает информацию от получателя о доставке этих данных, и, если такая информация не поступает, данные пересылаются повторно.
Работа протокола с установлением соединения включает в себя три основные фазы:
установление соединения;
обмен данными;
разрыв соединения.
Передача всех данных при работе с таким протоколом, в отличие от протокола без установления соединения, происходит за одну транзакцию, т. е. в фазе обмена данными не происходит обмена адресами между отправителем и получателем, поскольку эта информация передается на этапе установки соединения. Возвращаясь к телефонной аналогии, можно сказать, что нам в этом случае нет необходимости для того, чтобы сказать собеседнику очередное слово, вновь набирать его номер и устанавливать соединение. Заметим, что приводимая аналогия имеет одну неточность. Дело в том, что при телефонном разговоре все же устанавливается физическое соединение. Когда же мы говорим о соединении с точки зрения протоколов, то это соединение, скорее, умозрительное. К примеру, если вдруг при телефонном разговоре, неожиданно сломается телефонный аппарат вашего собеседника, вы тут же узнаете об этом, поскольку разговор незамедлительно прервется. А вот если происходит обмен данными между двумя хостами и один из них вдруг аварийно остановится, то для его "хоста-собеседника" соединение по прежнему будет существовать, поскольку для него не произошло ничего такого, что сделало бы недействительной хранящуюся у него информацию о состоянии.
В этом смысле работу с протоколом, требующим установления логического соединения можно сравнить с телефонным разговором. Когда мы звоним по телефону, мы сначала набираем номер (установление соединения), затем разговариваем (обмен данными) и по окончании разговора вешаем трубки (разрыв соединения).
Протокол без установления соединения обычно сравниваю с почтовой открыткой. Каждая открытка представляет собой самостоятельную единицу (пакет информации или дейтаграмму), которая обрабатывается в почтовом отделении независимо от других открыток. При этом на почте не отслеживается состояние переписки между двумя респондентами и, как правило, нет никакой гарантии, что ваша открытка попадет к адресату. Если на открытке указан неправильный адрес, она никогда не дойдет до получателя, и не возвратиться обратно к отправителю. А если вы захотите отправить вашему собеседнику новую порцию информации, то это уже будет другая транзакция, поскольку нужно будет писать новую открытку, указывать на ней адрес и т. д.
Как видим, у протоколов без установления соединения существует много недостатков и может возникнуть вопрос о надобности таких протоколов. Однако, использование проколов без установления логического соединения все-таки оправдано. Как правило, при помощи таких протоколов организуется связь одного хоста со многими другими, в то время как при использовании протоколов с установлением соединения связь организуется между парой хостов (по одному соединению на каждую пару). Важный момент заключается в том, что протоколы без установления логического соединения являются фундаментом, на котором строятся более сложные протоколы. К примеру, протокол TCP построен на базе протокола IP.
Протоколы транспортного уровня
Протоколами транспортного уровня в четырехуровневом стеке протоколов являются протоколы TCP и UDP.
Давайте рассмотрим, каким образом функционирует протокол TCP. Дело в том, что поскольку TCP-пакеты, иначе называемые сегментами, посылаются при помощи протокола IP, у TCP нет никакой информации о состоянии этих пакетов. Поэтому для того, чтобы хранить информацию о состоянии, TCP к базовому протоколу IP добавляет три параметра.
Во-первых, добавляется сегмент контрольной суммы содержащихся в пакете данных, что позволяет убедиться в том, что в принципе все данные дошли до получателя и не повредились во время транспортировки.
Во-вторых, к каждому передаваемому байту приписывается порядковый номер, что необходимо для определения того, совпадает ли порядок прибытия данных с порядком их отправки. И даже в том случае, если данные пришли не в том порядке, в котором были отправлены, наличие порядковых номеров позволит получателю правильно составить из этих данных исходное сообщение.
В-третьих, базовый протокол IP дополняется также механизмами подтверждения получения данных и повторной отправки, на тот случай, если данные не были доставлены.
Если с первыми двумя параметрами все более-менее понятно, то механизм подтверждения/повторной отправки достаточно сложен и его мы рассмотрим подробнее в другой раз.
Для того чтобы воспользоваться некоторыми советами в данном обзоре, необходимо вносить изменения в Реестр. Будьте предельно осторожны! Ошибки при редактировании системных файлов могут привести к серьезным проблемам.
Чтобы уберечься от неприятностей, скопируйте Реестр и другие важные файлы, прежде чем вносить в них какие-либо изменения. Сделать это просто.
Достаточно перейти в меню Start и щелкнуть на разделе Programs в Windows Me или All Programs в Windows XP. Выберите пункты Accessories (Стандартные), System Tools (Служебные) и System Restore (Восстановление системы).
Создайте точку восстановления, выбрав функцию Create a restore point и щелкните на кнопке Next. Дайте описание точки восстановления и щелкните на кнопке Next в Windows Me или Create в Windows XP.
Если в системе возникли неполадки, но запустить Windows все же удается, вновь обратитесь к System Restore (как описано выше) и выберите функцию восстановления прежнего состояния Restore my computer to an earlier time.
Если Windows не загружается, нажмите клавишу F8, когда дается старт попытке загрузить операционную систему. Пользователям Windows Me следует загрузиться в режиме Safe Mode и запустить System Restore. В Windows XP можно воспользоваться режимом Safe Mode или восстановить последнюю корректную конфигурацию (Last Known Good Configuration).
Для программирования расширенных хранимых процедур Microsoft предоставляет ODS (Open Data Service) API набор макросов и функций, используемых для построения серверных приложений позволяющих расширить функциональность MS SQL Server 2000.
Расширенные хранимые процедуры - это обычные функции написанные на С/C++ с применением ODS API и WIN32 API, оформленные в виде библиотеки динамической компоновки (dll) и призванные, как я уже говорил, расширять функциональность SQL сервера. ODS API предоставляет разработчику богатый набор функций позволяющих передавать данные клиенту, полученные от любых внешних источников данных (data source) в виде обычных наборов записей (record set). Так же, extended stored procedure может возвращать значения через переданный ей параметр (OUTPUT parametr).
Как работают расширенные хранимые процедуры.
* Когда клиентское приложение вызывает расширенную хранимую процедуру, запрос передаётся в TDS формате через сетевую библиотеку Net-Libraries и Open Data Service ядру MS SQL SERVER.
* SQL Sever находит dll библиотеку ассоциированную с именем расширенной хранимой процедуры и загружает её в свой контекст, если она не была загружена туда ранее, и вызывает расширенную хранимую процедуру, реализованную как функцию внутри dll.
* Расширенная хранимая процедура выполняет на сервере необходимые ей действия и передаёт набор результатов клиентскому приложению, используя сервис предоставляемый ODS API.
Особенности расширенных хранимых процедур.
* Расширенные хранимые процедуры - это функции выполняющиеся в адресном пространстве MS SQL Server и в контексте безопасности учётной записи под которой запущена служба MS SQL Server;
* После того, как dll библиотека с расширенными хранимыми процедурами была загружена в память, она остаётся там до тех пор, пока SQL Server не будет остановлен, или пока администратор не выгрузит её принудительно, используя команду :
DBCC DLL_name (FREE).
* Расширенная хранимая процедура запускается на выполнение так же, как и обычная хранимая процедура:
EXECUTE xp_extendedProcName @param1, @param2 OUTPUT
@param1 входной параметр
@param2 входной/выходной параметр
Внимание!
Так как расширенные хранимые процедуры выполняются в адресном пространстве процесса службы MS SQL Server, любые критические ошибки, возникающие в их работе, могут вывести из строя ядро сервера, поэтому рекомендуется тщательно протестировать Вашу DLL перед установкой на рабочий сервер.
Создание расширенных хранимых процедур.
Расширенная хранимая процедура эта функция имеющая следующий прототип:
Параметр pSrvProc указатель на SRVPROC структуру, которая является описателем (handle) каждого конкретного клиентского подключения. Поля этой структуры недокументированны и содеражат информацию, которую библиотека ODS использует для управления коммуникацией и данными между серверным приложением (Open Data Services server application) и клиентом. В любом случае, Вам не потребуется обращаться к этой структуре и тем более нельзя модифицоравать её. Этот параметр требуется указывать при вызове любой функции ODS API, поэтому в дальнейшем я небуду останавливаться на его описании.
Использование префикса xp_ необязательно, однако существует соглашение начинать имя расширенной хранимой процедуры именно так, чтобы подчеркнуть отличие от обычной хранимой процедуры, имена которых, как Вы знаете, принято начинать с префикса sp_.
Так же следует помнить, что имена расширенных хранимых процедур чувствительны к регистру. Не забывайте об этом, когда будете вызвать расширенную хранимую процедуру, иначе вместо ожидаемого результата, Вы получите сообщение об ошибке.
Если Вам необходимо написать код инициализации/деинициализации dll, используйте для этого стандартную функцию DllMain(). Если у Вас нет такой необходимости, и вы не хотите писать DLLMain(), то компилятор соберёт свою версию функции DLLMain(), которая ничего не делает, а просто возвращает TRUE. Все функции, вызываемые из dll (т.е. расширенные хранимые процедуры) должны быть объявлены, как экспортируемые. Если Вы пишете на MS Visual C++ используйте директиву __declspec(dllexport). Если Ваш компилятор не поддерживает эту директиву, опишите экспортируемую функцию в секции EXPORTS в DEF файле.
Итак, для создания проекта, нам понадобятся следующие файлы:
* Srv.h заголовочный файл, содержит описание функций и макросов ODS API;
* Opends60.lib файл импорта библиотеки Opends60.dll, которая и реализует весь сервис предоставляемый ODS API.
Microsoft настоятельно рекомендует, чтобы все DLL библиотеки реализующие расширенные хранимые процедуры экспортировали функцию:
Когда MS SQL Server загружает DLL c extended stored procedure, он первым делом вызывает эту функцию, чтобы получить информацию о версии используемой библиотеки.
Для написания своей первой extended stored procedure, Вам понадобится установить на свой компьютер:
- MS SQL Server 2000 любой редакции (у меня стоит Personal Edition). В процесе инсталляции обязательно выберите опцию source sample
- MS Visual C++ (я использовал версию 7.0 ), но точно знаю подойдёт и 6.0
Установка SQL Server -a нужна для тестирования и отладки Вашей DLL. Возможна и отладка по сети, но я этого никогда не делал, и поэтому установил всё на свой локальный диск. В поставку Microsoft Visual C++ 7.0 редакции Interprise Edition входит мастер Extended Stored Procedure DLL Wizard. В принципе, ничего сверх естественного он не делает, а только генерирует заготовку шаблон расширенной хранимой процедуры. Если Вам нравятся мастера, можете использовать его. Я же предпочитаю делать всё ручками, и поэтому не буду рассматривать этот случай.
Теперь к делу:
- Запустите Visual C++ и создайте новый проект - Win32 Dynamic Link Library.
- Включите в проект заголовочный файл - #include <srv.h>;
- Зайдите в меню Tools => Options и добавьте пути поиска include и library файлов. Если , при установке MS SQL Server, Вы ничего не меняли, то задайте:
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsInclude для заголовочных файлов;
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsLib для библиотечных файлов.
- Укажите имя библиотечного файла opends60.lib в опциях линкера.
На этом подготовительный этап закончен, можно приступать к написанию своей первой extended stored procedure.
Постановка задачи.
Прежде чем приступать к программированию, необходимо чётко представлять с чего начать, какой должен быть конечный результат, и каким способом его добиться. Итак, вот нам техническое задание:
Разработать расширенную хранимую процедуру для MS SQL Server 2000, которая получает полный список пользователей зарегистрированных в домене, и возвращает его клиенту в виде стандартного набора записей (record set). В качестве первого входного параметра функция получает имя сервера содержащего базу данных каталога (Active Directory), т.е имя контролера домена. Если этот параметр равен NULL, тогда необходимо передать клиенту список локальных групп. Второй параметр будет использоваться extended stored procedure для возварата значения результата успешной/неуспешной работы (OUTPUT параметр). Если, расширенная хранимая процедура выполнена успешно, тогда необходимо передать количество записей возвращённых в клиентский record set , если в процессе работы не удалось получить требуемую информацию, значение второго параметра необходимо установить в -1, как признак неуспешного завершения.
.
А вот шаблон расширенной хранимой процедуры, который нам предстоит наполнить содержанием:
Работа с входными параметрами
В этой главе я не хочу рассеивать Ваше внимание на посторонних вещах, а хочу сосредоточить его на работе с переданными в расширенную хранимую процедуру параметрами. Поэтуму мы несколько упростим наше техническое задание и разработаем тольку ту его часть, которая работает с входными параметрами. Но сначал не много теории
Первое действие, которое должна выполнить наша exteneded stored procedure , - получить параметры, которые были переданы ей при вызове. Следуя приведённому выше алгоритму нам необходимо выполнить следующие действия:
- Определить кол-во переданных параметров;
- Убедится, что переданные параметры имеют верный тип данных;
- Убедиться, что указанный OUTPUT параметр имеет достаточную длину, для сохранения в нём значения возвращаемого нашей extended stored procedure.
- Получить переданные параметры;
- Установить значения выходного параметра как результат успешного/неуспешного завершения работы extended stored procedure .
Теперь рассмотрим подробно каждый пункт:
Определение количества переданных в расширенную хранимую процедуру параметров
Для получения количества переданных параметров необходимо использовать функцию:
.
При успешном завершении функция возвращает количество переданных в расширенную хранимую процедуру параметров. Если extended stored procedure была вызвана без параметров - srv_rpcparams ввернёт -1. Параметры могут быть переданы по имени или по позиции (unnamed). В любом случае, нельзя смешивать эти два способа. Попытка передачи в функцию входных параметров по имени и по позиции одновременно - приведёт к возникновению ошибки, и srv_rpcparams вернёт 0 .
[pagebreak]
Определение типа данных и длины переданых параметров
Для получения информации о типе и длине переданных параметров Microsoft рекомендует использовать функцию srv_paramifo. Эта универсальная функция заменяет вызовы srv_paramtype, srv_paramlen, srv_parammaxlen, которые теперь считаются устаревшими. Вот её прототип:
.
.
.
.
.
.
.
.
.
.
pByte - указатель на переменную получающую информацию о типе входного параметра;
pbType задаёт порядковый номер параметра. Номер первого параметра начинается с 1.
pcbMaxLen - указатель на переменную, в которую функция заносит максимальное значение длины параметра. Это значение обусловлено конкретным типом данных переданного параметра, его мы и будем использовать, чтобы убедиться втом, что OUTPUT параметр имеет достаточную длину для сохранения передаваемых данных.
pcbActualLen указатель на реальную длину параметра переданного в расширенную хранимую процедуру при вызове. Если передаваемый параметр имеет нулевую длину, а флаг pfNull устанавлен в FALSE то (* pcbActualLen) ==0.
pbData - указатель на буфер, память для которого должна быть выделена перед вызовом srv_paraminfo. В этом буфере функция размещает полученные от extended stored procedure входные параметры. Размер буфера в байтах равен значению pcbMaxLen. Если этот параметр установлен в NULL, данные в буфер не записываются, но функция корректно возвращает значения *pbType, *pcbMaxLen, *pcbActualLen, *pfNull. Поэтому вызывать srv_paraminfo нужно дважды: сначала с pbData=NULL, потом, выделив необходимый размер памяти под буфер равный pcbActualLen, вызвать srv_paraminfo второй раз, передав в pbData указатель на выделенный блок памяти.
pfNull указатель на NULL-флаг. srv_paraminfo устанавливает его в TRUE, если значение входного параметра равно NULL.
Проверка, является ли второй параметр OUTPUT параметром.
Функция srv_paramstatus() предназначена для определения статуса переданного параметра:
.
.
.
.
.
n - номер параметра переданного в расширенную хранимую процедуру при вызове. Напомню: параметры всегда нумеруются с 1.
Для возврата значения, srv_paramstatus использует нулевой бит. Если он установлен в 1 переданный параметр является OUTPUT параметром, если в 0 обычным параметром, переданным по значению. Если, exteneded stored procedure была вызвана без параметров, функция вернёт -1.
Установка значения выходного параметра.
Выходному параметру, переданному в расширеную хранимую можно передать значение используя функцию srv_paramsetoutput. Эта новая функция заменяет вызов функции srv_paramset, которая теперь считается устаревашай, т.к. не поддерживает новые типы данных введённые в ODS API и данные нулевой длины.
.
.
.
.
.
.
.
.
n - порядковый номер параметра, которому будет присвоено новое значение. Это должен быть OUTPUT параметр.
pbData указатель на буфер с данными, которые будут посланы клиенту для установки значения выходного параметра.
cbLen длина буфера посылаемых данных. Если тип данных переданного OUTPUT параметра определяет данные постоянной длины и не разрешает хранение значения NULL (например SRVBIT или SRVINT1), то функция игнорирует параметр cbLen. Значение cbLen=0 указывает на данные нулевой длины, при этом парметр fNull должен быть установлен в FALSE.
fNull установите этот его в TRUE, если возвращаемому параметру необходимо присвоить значение NULL, при этом значение cbLen должно быть равно 0, иначе функция завершится с ошибкой. Во всех остальных случаях fNull=FALSE.
В случае успешного завершения функция возвращает SUCCEED. Если возвращаемое значение равно FAIL, значит вызов был неудачным. Всё просто и понятно
Теперь мы достаточно знаем, для того чтобы написать свою первую расширенную хранимую процедуру, которая будет возвращать значение через переданный ей параметр.Пусть, по сложившейся традиции, это будет строка Hello world! Отладочну версию примера можно скачать здесь.
. Не рассмотренными остались функции srv_sendmsg и srv_senddone. Функция srv_sendmsg используется для посылки сообщений клиенту. Вот её прототип:
msgtype определяет тип посылаемого клиенту сообщения. Константа SRV_MSG_INFO обозначает информационное сообщение, а SRV_MSG_ERROR сообщение об ошибке;
msgnum номер сообщения;
class - степень тяжести возникшей ошибки. Информационные сообщения имеют значение степени тяжести меньшее или равное 10;
state номер состояния ошибки для текущего сообщения. Этот параметр предоставляет информацию о контексте возникшей ошибки. Допустимые значения лежат в диапазоне от 0 до 127;
rpcname в настоящее время не используется;
rpcnamelen - в настоящее время не используется;
linenum здесь можно указать номер строки исходного кода. По этому значению, в последствие будет легко установить в каком месте возникла ошибка. Если Вы не хотите использовать эту возможность, тогда установите linenum в 0;
message указатель на строку посылаемую клиенту;
msglen определяет длину в байтах строки сообщения. Если это строка заканчивается нулевым символом, то значение этого параметра можно установить равным SRV_NULLTERM.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
В процессе работы расширенная хранимая процедура должна регулярно сообщать клиентскому приложению свой статус, т.е. посылать сообщения о выполненных действиях. Для этого и предназначена функция srv_senddone:
status - статус флаг. Значение этого параметра можно задавать использую логические операторы AND и OR для комбинирования констант приведённых в таблице:
Status flag Описание
SRV_DONE_FINAL Текущий набор результатов является окончательным;
SRV_DONE_MORE Текущий набор результатов не является окончательным следует ожидать очердную порцию данных;
SRV_DONE_COUNT Параметр count содержит верное значение
SRV_DONE_ERROR Используется для уведомления о возникновении ошибок и немедленном завершении.
into зарезервирован, необходимо установить в 0.
count количество результирующих наборов данных посылаемых клиенту. Если флаг status установлен в SRV_DONE_COUNT, то count должен содержать правильное количество посылаемый клиенту наборв записей.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
Установка расширенных хранимых процедур на MS SQL Server 2000
1.Скопируйте dll библиотеку с расширенной хранимой процедурой в каталог binn на машине с установленным MS SQL Server. У меня этот путь следующий: C:Program FilesMicrosoft SQL ServerMSSQLBinn;
2.Зарегистрирйте расширенную хранимую процедуру на серверt выполнив следующий скрипт:
Заключение
На этом первая часть моей статьи закончена. Теперь я уверен Вы готовы справиться с нашим техническим заданием на все 100%. В следующей статье Вы узнаете:
- Типы данных определённые в ODS API;
- Особенности отладки расширенных хранимых процдур;
- Как формировать recordset-ы и передавать их клиентскому приложению;
- Чстично мы рассмотрим функции Active Directory Network Manegment API необходимые для получения списка доменных пользователей;
- Создадим готовый проект (реализуем наше техническое задание)
Надеюсь - до скорой встречи!
В состав версий Windows Server 2003 Service Pack 1 (SP1) и Windows XP SP2 входит размещаемый в системе брандмауэр Windows Firewall, гораздо более эффективный, чем его предшественник, Internet Connection Firewall (ICF). В отличие от ICF, который поставлялся с Windows 2003 и XP, Windows Firewall подходит для развертывания в масштабах предприятия благодаря возможности управлять политиками брандмауэра из единого центра, нескольким интерфейсам настройки и множеству новых функций безопасности. В этой статье я расскажу о том, как лучше подойти к планированию, настройке конфигурации и применению брандмауэра на предприятии.
Подготовительный этап
Важно помнить о выбираемом по умолчанию режиме Windows Firewall. В XP SP2 брандмауэр Windows Firewall активен по умолчанию, а в Windows 2003 SP1 его стандартное состояние — выключенное, если только SP1 не развертывается на системе с запущенным ICF. В этом случае режим брандмауэра не изменяется. Если пакет SP1 размещен на установочном компакт-диске с операционной системой, то Windows Firewall всегда активизируется в режиме включения по умолчанию, когда в процессе установки происходит соединение со службой Windows Update для получения последних обновлений. Поэтому, если развернуть XP SP2, не уделяя должного внимания настройке Windows Firewall, и опрометчиво принять стандартные параметры, можно лишиться доступа к инструментарию для дистанционного управления настольными компьютером. Если администратор не готов использовать Windows Firewall или работает с брандмауэром независимого поставщика, то можно спокойно отключить Windows Firewall и развернуть SP2 без него.
Если для аутентификации пользователей применяется Active Directory (AD), а настольные компьютеры являются членами домена с соответствующими учетными записями, то самый простой способ настроить Windows Firewall — задействовать объекты групповой политики Group Policy Object (GPO). После установки XP SP2 на настольных компьютерах параметры брандмауэра настраиваются при перезагрузке машин и каждый раз при обновлении политики. Если используется продукт управления каталогами независимого поставщика или на предприятии имеются не управляемые администратором компьютеры, которые не входят в состав домена AD, то для настройки Windows Firewall вместо объектов GPO можно использовать пакетные файлы или сценарии. Настроить конфигурацию брандмауэра можно и в ходе автоматизированных или интерактивных процедур установки XP SP2.
Настройка Windows Firewall
Приступая к настройке конфигурации Windows Firewall, следует помнить об основных характеристиках брандмауэра:
* Windows Firewall не выполняет фильтрации исходящего трафика, то есть не ограничивает его. Если предприятие нуждается в фильтрации исходящего трафика, следует использовать брандмауэр независимого поставщика.
* Возможности Windows Firewall шире, чем у ICF: в Windows Firewall можно настраивать исключения, чтобы разрешить входящий трафик с учетом не только транспортного протокола (TCP или UDP) и номера порта, но и приложения (например, одноранговой программы обмена файлами).
* Можно уточнить исключения по области действия, то есть разрешить соединения от всех компьютеров, от компьютеров в указанных подсетях, только из локальной подсети или от компьютеров с определенными IP-адресами.
* Windows Firewall активизируется по умолчанию для всех сетевых соединений, но для каждого сетевого интерфейса можно настроить разные правила брандмауэра.
* Настраивать Windows Firewall может только администратор. Если управление брандмауэром централизованное (через AD или GPO), то можно лишить локальных администраторов права изменять параметры.
* С помощью Windows Firewall можно ограничить трафик IPv4 и IPv6.
* Windows Firewall располагает двумя профилями, Domain и Standard. Профиль Domain активизируется, если компьютер подключен к сети с контроллерами домена (DC), членом которого он является. Профиль Standard применяется, если компьютер подключен к другой сети, например общедоступной беспроводной сети или скоростному соединению в номере отеля. Рекомендуется настроить профили Domain и Standard для серверов и настольных компьютеров, а также для ноутбуков.
Прежде чем настраивать конфигурацию Windows Firewall, следует провести инвентаризацию приложений на рабочих станциях и серверах, которые могут организовать оконечные точки соединений; портов, используемых приложениями и операционной системой; источников трафика для каждой хост-машины с Windows Firewall. Для мобильных систем, таких как ноутбуки, в ходе инвентаризации следует учитывать различную природу сетевого трафика при подключении системы к корпоративной сети с контроллерами домена и активным профилем Domain брандмауэра Windows Firewall, в отличие от системы, подключенной к общедоступной сети с активным профилем Standard. Нужно всегда выбирать профиль Standard и разрешать только необходимый входящий трафик через брандмауэр, чтобы свести к минимуму угрозу для подключенных к сети мобильных машин.
В Windows Firewall определены четыре встроенные административные службы, представляющие типовые исключения для любой политики брандмауэра: File and Print, Remote Administration, Remote Desktop и Universal Plug and Play (UpnP). Remote Administration обеспечивает управление системой через типовые административные интерфейсы и подсистемы, такие как Windows Management Instrumentation (WMI) и вызов удаленных процедур (remote procedure call — RPC). Remote Desktop позволяет подключиться к одной системе с другой через RDP и используется при запросе на поддержку Remote Assistance. Администраторы часто применяют Remote Desktop для подключения к удаленным серверам, которыми они управляют. Протокол UpnP обеспечивает корректную работу устройств, которые обнаруживают и динамически настраивают друг друга с учетом активных приложений и служб. Типовой пример использования UpnP — взаимодействие XP с UPnP-совместимым широкополосным маршрутизатором при запуске MSN Messenger, в результате которого аудио и видеосоединения устанавливаются через встроенный брандмауэр маршрутизатора.
При настройке профилей Domain и Standard брандмауэра Windows Firewall рекомендуется задать исключения для конкретных приложений. Благодаря исключению приложение сможет установить любые нужные оконечные точки и принимать через них трафик. Существуют две веские причины, чтобы назначать исключения для приложений. Во-первых, проще определить и описать приложения, нежели отдельные используемые ими порты, особенно потому, что порты, используемые многими приложениями, документированы не полностью или назначаются динамически. Во-вторых, многие приложения, в том числе несанкционированные, используют те же порты, что и легальные приложения; указав приложения вместо портов, можно лишить неутвержденные приложения возможности установить оконечные точки соединения. Всегда, когда возможно, рекомендуется не делать исключений для профиля Standard и отклонять все входящие соединения.
Windows Firewall для серверов
Microsoft не дает специальных рекомендаций по настройке Windows Firewall для серверов. По умолчанию брандмауэр блокирован, если только пакет Windows Server 2003 SP1 не устанавливается на системе с активным ICF, однако брандмауэром можно воспользоваться для укрепления безопасности сервера Windows 2003. Применяя брандмауэр на сервере, следует помнить, что серверы по своей природе служат для размещения приложений и служб, с которыми устанавливают соединения приложения и службы на других серверах, настольных компьютерах и ноутбуках. Прежде чем активизировать Windows Firewall на сервере, следует продумать его конфигурацию.
Для некоторых серверов настроить Windows Firewall не составляет труда. Например, неуправляемому автономному Web-серверу в демилитаризованной зоне (DMZ) требуется принимать только входящие соединения через порт 80/TCP (HTTP) или 443/TCP (HTTP Secure-HTTPS), если установлен сертификат и активизирована защита SSL (Secure Sockets Layer).
На сервере с двумя или несколькими интерфейсами, из которых один интерфейс подключен к Internet, а другие — к корпоративным сетям, можно активизировать Windows Firewall, а затем отключить его на всех интерфейсах, кроме Internet, и настроить брандмауэр, разрешив только необходимые входящие соединения на интерфейсе Internet.
В простых файл- и принт-серверах корпоративной сети, входящих в состав домена, можно активизировать Windows Firewall и задействовать встроенную службу File and Printer Sharing для подключения пользователей к этим серверам. Можно также использовать Windows Firewall для защиты сервера, службы которого прослушивают известные порты, например сервера базы данных Microsoft SQL Server 2000. Для этого следует разрешить в брандмауэре трафик через соответствующие порты.
Настроить Windows Firewall на сервере можно с помощью мастера Security Configuration Wizard (SCW). SCW, факультативный компонент Windows 2003 SP1, уменьшает поверхность атаки сервера, задавая роль или роли для сервера. SCW содержит ролевую информацию для DC и других серверов инфраструктуры; он блокирует необязательные службы и ограничивает входящий трафик через Windows Firewall.
Windows Firewall не следует размещать на некоторых серверах, в том числе контроллерах домена AD и некоторых серверах приложений, которые прослушивают большой диапазон портов или используют динамические порты, таких как серверы Exchange Server 2003. В последнем случае можно развернуть Windows Firewall, если серверы и клиенты, подключенные к серверам Exchange, входят в состав домена. Брандмауэр настраивается на передачу аутентифицированного трафика IPsec в обход Windows Firewall (этот прием будет рассмотрен ниже), а клиенты настраиваются на использование IPsec.
На многих серверах, в том числе таких, на которых выполняется множество приложений и служб, необходима выборочная настройка Windows Firewall. Требуется указать порты, прослушиваемые приложениями и службами, отбросить необязательные порты и настроить Windows Firewall для необходимых портов. Определить открытые порты и прослушивающие их приложения и службы можно с помощью команды Netstat (netstat.exe), усовершенствованной в последних пакетах обновлений. Указав в командной строке
netstat -a -b
можно увидеть все открытые порты TCP (независимо от состояния) и порты UDP в системе, идентификатор процесса (PID) для каждого активного соединения (образец выходной информации приведен на экране 1). Как уже упоминалось, Windows Firewall можно настроить на разрешение входящего трафика для поименованных приложений, независимо от прослушиваемых ими портов. Единственный недостаток Netstat заключается в том, что команда выдает лишь «моментальный снимок» системы. С ее помощью нельзя идентифицировать приложения, службы и их порты, если эти приложения неактивны в момент запуска Netstat. Чтобы получить достоверную картину, можно сделать несколько снимков в разное время.
Более простая альтернатива Netstat — инструмент Port Reporter, который можно получить по адресу http://support.microsoft.com/?kbid=837243. Программа устанавливается как служба и регистрирует сетевую активность, в том числе подробные сведения об активных программах и службах, и даже учетную запись пользователя, с которой работает приложение или служба. С помощью сопутствующего инструмента Port Reporter Parser (http://www.support.microsoft.com/?kbid=884289) можно извлечь данные из журналов, генерируемых Port Reporter. Правильно настроив и запуская Port Reporter в течение определенного промежутка времени, можно идентифицировать приложения, которые открывают порты сервера и должны быть настроены в Windows Firewall по приложениям или отдельным портам. Длительность применения Port Reporter зависит от приложений и особенностей работы пользователей. Предостережение: Port Reporter может слегка снизить производительность системы, а журналы очень велики. Файлы журналов следует записывать на быстрый диск с достаточным количеством свободного места.
Рекомендуется активизировать функции протоколирования Windows Firewall после завершения настройки серверов. Можно записывать сведения об успешных и неудачных соединениях. Если после настройки и активизации Windows Firewall возникают проблемы при выполнении некоторых приложений, то с помощью информации из журналов можно определить дополнительные порты, которые следует открыть. Для настройки функций протоколирования следует открыть панель управления, запустить утилиту Windows Firewall, щелкнуть на вкладке Advanced, а затем на кнопке Settings в разделе Security Logging. Откроется диалоговое окно Log Settings (экран 2). Журнал Windows Firewall следует сохранять на быстром диске, а максимальный размер журнала должен быть достаточным для записи необходимой информации в течение длительного времени. Проверив корректность настройки Windows Firewall, можно отключить протоколирование.
Экран 2. Настройка протоколирования в Windows Firewall
Windows Firewall можно настроить и таким образом, чтобы передавать аутентифицированный трафик IPsec от доверенных машин в обход брандмауэра. В этот режим можно перевести серверы и рабочие станции, чтобы они пропускали только необходимый клиентский трафик, одновременно обеспечивая неограниченный доступ для администрирования рабочих станций и серверов.
Полная готовность
После завершения подготовки к развертыванию Windows Firewall рекомендуется активизировать брандмауэр сначала для пилотной группы пользователей. Если в процессе пробного развертывания возникнут трудности, следует активизировать режим протоколирования; в журналах содержится информация, которая поможет определить причину проблем. После устранения неполадок и успешного развертывания Windows Firewall брандмауэр станет неоценимым компонентом системы безопасности предприятия.
Случалось ли вам переустанавливать Windows? Те кто сталкивался с этим, знают сколько времени уходит на то чтобы установить все необходимые драйвера, программное обеспечение и настроить систему. Но если позаботиться заранее, восстановление полностью рабочей системы займет не более получаса.
ASR (Automated System Recovery) - это механизм, позволяющий восстановить всю информацию системного раздела в случае серьезного сбоя, когда другие методы восстановления уже не могут помочь. ASR заменил механизм ERD (Emergency Repair Disk), который использовался в предыдущих версиях Windows. В отличие от ERD, восстанавливавшего только системные настройки, ASR способен восстанавливать весь системный раздел, включая программное обеспечение, драйвера, документы пользователя, системные настройки на момент создания набора ASR.
Создание набора ASR.
Для того чтобы воспользоваться возможностью механизма ASR, необходимо создать набор ASR, состоящий из 2-х частей: непосредственно архива с данными, который может быть размещен на записываемом CD, магнитной ленте, несистемном разделе жесткого диска или другом жестком диске и дискеты, на которую записываются данные, необходимые для восстановления системы. Создавать наборы ASR могут пользователи с правами администратора.
Чтобы создать набор ASR, запустите программу 'Архивация данных' ('Пуск - Все программы - Стандартные - Служебные - Архивация данных' или наберите ntbackup.exe из меню 'Пуск - Выполнить'). Перейдите в расширенный режим. По умолчанию не все файлы включаются в создаваемый архив. Поэтому перед созданием набора ASR стоит посмотреть список исключенных файлов. Для этого перейдите на вкладку 'Сервис - Параметры - Исключение файлов'. По умолчанию в этом списке находятся: файл подкачки (pagefile.sys), файл создаваемый при использовании спящего режима (hiberfil.sys), контрольные точки восстановления, временные файлы и некоторые файлы журналов. Но в зависимости от установленного программного обеспечения и ранее внесенных изменений этот список может быть больше или меньше. Например, при установленном Norton Antivirus в список исключенных файлов попадает база описаний вирусов, и при восстановлении системы вам придется или скачивать новую базу описаний из интернет, или переустанавливать Norton Antivirus. Внимательно проверьте весь список, при необходимости внесите в него изменения. После этого можно запустить мастер подготовки аварийного восстановления для создания набора ASR - выберите 'Сервис - Мастер аварийного восстановления системы'. Укажите путь для создаваемого архива. Не указывайте в качестве пути системный раздел вашего жесткого диска. После сбора необходимой информации начнется процесс архивации. Если вы размещаете архив на разделе жесткого диска с файловой системой FAT32, обратите внимание на информационную строку 'Ожидалось, байт' - если размер создаваемого архива оценен более чем в 4 Гб, следует прервать процесс архивации и уменьшить размер архива путем исключения из него некоторых несистемных файлов, которые можно сохранить в отдельном архиве, иначе создание набора ASR не будет завершено должным образом. После этого вновь запустите мастер подготовки аварийного восстановления. После создания архива вам будет предложено вставить дискету для записи на нее параметров восстановления. На этом создание набора ASR закончено.
Восстановление системы с помощью набора ASR.
Для восстановления системы потребуется набор ASR (архив+дискета) и загрузочный диск Windows XP. Загрузитесь с помощью загрузочного диска, выберите установку Windows XP. При появлении в строке состояния приглашения нажмите клавишу F2 - появится сообщение 'Вставьте диск под названием Диск автоматического восстановления системы Windows в дисковод для гибких дисков'. После считывания с дискеты необходимых для восстановления данных и загрузки основных драйверов будет произведено форматирование системного раздела и начальная установка Windows XP. Далее будет запущен мастер аварийного восстановления системы и произведено восстановление файлов из архива набора ASR. После восстановления файлов будет произведена перезагрузка и вы получите Windows XP со всеми установленными программами, документами и системными настройками на момент создания набора ASR.
А что делать, если по каким-то причинам диcкета с параметрами восстановления утрачена? Можно переписать на дискету файлы asr.sif и asrpnp.sif из каталога ..\Windows\repair\ , но только в том случае, если вы после создания набора ASR не запускали мастер создания набора ASR. Другой вариант - это восстановление файлов asr.sif и asrpnp.sif непосредственно из созданного архива. Для этого запустите программу 'Архивация данных' в расширенном режиме, перейдите на вкладку 'Восстановление и управление носителем'. В левой части окна выберите нужный архив, если его нет в списке, добавьте его, воспользовавшись пунктом 'Сервис - Каталогизировать архивный файл'. В левой части окна выделите папку ..\Windows\repair\, а в правой установите флажки для файлов asr.sif и asrpnp.sif. В меню 'Восстановить файлы в...' выберите 'Одну папку', в качестве пути укажите дисковод со вставленной дискетой, и нажмите кнопку 'Восстановить'.
Используйте восстановление системы с помощью ASR только в том случае, если другие способы восстановления, такие как средства консоли восстановления или загрузка последней удачной конфигурации не могут помочь, если утерян ключ на вход в систему установленный с помощью программы syskey или произошел серьезный сбой в файловой системе. Помните, что механизм ASR восстанавливает состояние системного раздела на момент создания набора ASR, все изменения внесенные в систему после создания набора ASR, будут утрачены.
Для целей создания образа всего жесткого диска или системного раздела существуют также программы сторонних разработчиков, такие как Acronis True Image, PowerQwest Drive Image, Paragon Drive Backup, Norton Ghost и другие.
В мире информационных технологий такое понятие, как доступность сайта - это одна из самых важных составляющих. В Сети уже есть достаточное количество сервисов, с помощью которых можно проследить “доступность” (uptime - время работы). В данной статье рассмотрим три таких сервиса, один из которых работает на русском языке.
Бинoкль (http://www.binokl.info/) - изначально сервис разработан для хостинг-компаний, веб-мастеров и интернет-провайдеров. В зависимости от выбранного тарифного пакета проверка доступности (uptime'а) вашего сервера происходит через 15, 20 или 30 минут.
Если вам лень каждый раз заходить в раздел статистики и смотреть показатели работы хостинга, то можно настроить автоматическое уведомление на e-mail, когда ваш сервер будет недоступен. Предусмотрена и отправка отчетов за определенны интервал времени - раз в неделю, месяц.
Есть возможность установить у себя на сайте графическую кнопку, которая будет информировать о том, что ваш сайт находится под наблюдением сервиса "Бинокль". Единственный недостаток такой кнопки - это ее информативность лишь в популяризации сервиса, потому как числовых данных она не выдает.
mon.itor.us (http://mon.itor.us/) - uptime сервис от американской компании. Очень информативен и предлагает возможность контроля множества параметров. Информация может выводиться в виде графика, таблицы или диаграммы - это кому как удобнее и понятнее воспринимать. Также можно организовать получение уведомлений через e-mail. Среди недостатков - это удаленность сервера от просторов рунета, что, естественно, замедляет проверку хостинга на доступность.
Montastic (http://montastic.com/) - простой (можно сказать, что даже очень простой), но, тем не менее, удобный сервис для определения uptima'а. Здесь статистика отсутствует как таковая, и вообще есть только два состояния - работает и не работает. Но изюминка в способах того, как вы узнаете статус сайта - это и рассылка по электронной почте, подписка на RSS и даже Yahoo Widget.
Интерфейс, как и функциональность весьма прост, просто вводите адрес сайта, e-mail и все! В принципе если вы не заморачиваетесь подсчетом денег, которые вы потеряли пока ваш сайт не работает или у вас нет желания высылать подробные жалобные письма в адрес своего хостера, то этот сервис то, что вам надо.
Сделаем выводы:
mon.itor.us - следует использовать только в том случае, если ваш сайт (а желательно и вы тоже) живет близко к этому сервису, то он просто идеально подходит для вас, только следите чтобы ваш сайт работал всегда.
Montastic - этот сервис для тех, кому нужен ответ - работает/не работает сайт
Бинoкль - подробный, надежный и главное что на русском языке.
Поиск
