Эта книга - отличное начало для тех, кто хочет научиться писать CGI-npoграммы, обеспечивающие вывод динамически изменяемых данных на веб-сайте, и уже немного знаком с языком Perl, пользующимся большой популярностью среди веб-разработчиков. Данное издание,в основу которого положен бестселлер `CGI программирование в WWW`, полностью переписано, с целью познакомить читателей с современными технологиями, доступными благодаря модулю CGI.pm и последним версиям языка Perl. В книге приводятся примеры создания высокопроизводительных и безопасных CGI-приложений, подробно описывается модуль CGI.pm, дан обзор протокола HTTP, обсуждается применение JavaScript для обработки форм, работа с базами данных, вывод динамической графики, создание поисковой системы и системына основе XML, а также многое другое. Данное издание будет прекрасным руководством и незаменимым справочником. Содержащийся в нем материал позволит вам стать хорошим CGI-разработчиком.
Эта книга представляет собой набор примеров с сопровождающими объяснениями, которые иллюстрируют наиболее важные возможности языка С++ с концентрацией на решении объектно-ориентированных проблем. Программисты, делающие использовать С++, смогут значительно ускорить процесс изучения, если будут иметь перед глазами хорошо написанные программы, сопровождаемые ясными комментариями, которые позволяют шаг за шагом освоить приемы программирования на С++.
Основная цель книги состоит в демонстрации преимуществ объектно-ориентированного программирования и в поощрении использования объектно-ориентированных возможностей С++. Подробно рассматриваются новейшие возможности С++, включая множественное наследование, которому посвящен целый раздел, содержащий множество примеров.
В книге имеется ряд вопросов "Что если", которые предвосхищают те вопросы, которые могут возникнуть у читателя. Эти вопросы позволяют более детально изучить рассматриваемый предмет.
Эта книга предназначена для профессиональных программистов, специалистов по компьютерам, студентов, изучающих компьютеры, руководителей групп программистов и инженеров желающих в полной мере использовать возможности языка С++.
Подробный справочник ни языку Perl, содержащий описание синтаксиса, дополненное основными сведениями об использовании языка (введением в предмет). Содержит сотни примеров и готовых решений.
Язык C++ является в настоящее время одним из самых распространенных языков программировании, но одновременно и одним из самых трудных для изучения. Книга «C++: учебный курс» поможет быстро, эффективно и с наименьшими затратами освоить все основные приемы создания приложений на C++. Для изучения всех возможностей языка требуются объемные руководства и справочники, но эта книга даст вам «стартовый толчок», поможет понять структуру языка, принципы обьектно-ориентированного программирования, методику проектирования и создания приложений. Учебный материал, содержащийся в 26-ти уроках, основан на практических примерах и сопровождается исходным кодом программ. Для его освоения не требуется никакой предварительной подготовки. Книга может быть использована в качестве учебного пособия для студентов, изучающих язык C++.
Учебное пособие позволяет получить профессиональные навыки создания сайтов в Интернете. Оно поможет сформировать у обучаемых творческий подход, способность к самостоятельному и инициативному решению проблем, умение использовать типовые инструментально-технологические средства и эффективно работать в неоднородных командах, что требуется для личностного развития и профессионального самоопределения. Каждая тема учебного пособия представляет собой законченный учебный модуль, включающий теоретический материал, задания для самостоятельной работы, темы рефератов. К учебному пособию прилагается CD-ROM, содержащий результаты выполнения упражнений, демонстрационные плакаты, спецификацию языка HTML. Для учащихся старших классов информационно-технологического, физико-математического, естественно-научного и гуманитарного профилей.
Книга представляет собой классический учебник для высшей школы, содержащий глубокое изложение вопросов, связанных с абстракцией и структурами данных, а также их реализацией на языке C++. Помимо предоставления прочных основ методов абстракции данных, в ней особо подчеркивается различие между спецификацией и реализацией, что является принципиально важным в объектно-ориентированном подходе. В книге подробно обсуждаются ключевые понятия объектно-ориентированного программирования, включая инкапсуляцию, наследование и полиморфизм, однако в центре внимания всегда находится именно абстракция данных, а не синтаксические конструкции языка C++.
Книга будет полезна всем, кто заинтересован в глубоком изучении важнейших аспектов ООП и полном освоении соответствующих возможностей языка C++.
Подробный справочник по языку Perl, содержащий описание синтаксиса, дополненное
основными сведениями об использовании языка (введением в предмет).
Содержит сотни примеров и готовых решений. Справочная информация относится
не только к синтаксису языка, нои к решению всех возможных задач,
возникающих у программистов на Perl, от самых простых до самых сложных.
В данной статье приведены общие сведения об организации работы системы 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С:Предприятие обладает некоторой сущностью - внутренним идентификатором, который уникален во всей распределенной системе. То есть один и тот же объект не может быть введен в двух узлах. Даже при полном соответствии кодов, номеров и всех данных это будут два разных объекта. Такой принцип необходим для четкой работы системы со всех точек зрения.
Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.
Поэтому, на наш взгляд, решение проблемы должно лежать в области администрирования системы. Технология работы пользователей должна быть построена таким образом, чтобы ввод объекта производился на одном узле.
В отдельных случаях может использоваться следующее решение. В справочник заранее вносится некоторое количество новых элементов со специальными кодами или в специальную группу. При появлении необходимости ввода нового товара реально не вводится новый элемент, а изменяется один этих элементов. При этом административными силами должно быть обеспечено идентичное изменение одного и того же "зарезервированного" объекта в тех узлах распределенной ИБ, в которой он должен быть использован до обмена данными. При обмене данными сами реквизиты элемента будут системой синхронизированы, а ссылки в других объектах, разумеется будут идентичными, так как использовался один и тот же объект.
В любых случаях следует учитывать, что раздельный ввод и использование объектов потребует от пользователей правильного ввода данных. Так, например, при вводе нового товара в двух узлах с разными ценами могут иметь место серьезные ошибки в оформлении документов.
Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".
Из приложений Delphi вы можете получить доступ к .MDB-файлам Microsoft Access, используя драйверы ODBC. Delphi действительно может дать все необходимое, но некоторые вещи не столь очевидные. Вот шаги для достижения вашей цели.
Что вам нужно: Первое: проверьте, установлен ли ODBC Administrator (файл ODBCADM.EXE в WINDOWS\SYSTEM, вам также необходим файл DBCINST.DLL для установки новых драйверов и ODBC.DLL). Администратор ODBC должен присутствовать в Панели Управления в виде иконки ODBC. Если у вас его не было, то после установки Delphi он должен появиться. Если вы получаете сообщение типа "Your ODBC is not up-to-date IDAPI needs ODBC greater then 2.0", у вас имеется старая версия администратора и вы должны обновить ее до версии, включенной в поставку Delphi. Проверьте, имеете ли вы доступ к драйверу Access ODBC, установленному в Windows. Вы можете сделать это, щелкнув на "Drivers" в диалоговом окне "Data Sources", появляющемся при запуске ODBC Administrator. Delphi должна в диалоге добавить пункты Access Files (*.mdb) и Access Data (*.mdb), работающие с файлами Access 1.10 и использующие драйвер SIMBA.DLL (имейте в виду, что для данного DLL необходимы также файлы RED110.DLL и SIMADMIN.DLL, устанавливаемые для вас Delphi). Данные файлы должны поставляться с дистрибутивом вашей программы как часть ReportSmith Runtime библиотеки. Если вы хотите работать с файлами Access 2.0 или 2.5, вам необходимо иметь другой набор драйверов от Microsoft. Ключевой файл - MSAJT200.DLL, также необходимы файлы MSJETERR.DLL и MSJETINT.DLL. В США набор ODBC Desktop Drivers, Version 2.0. стоит $10.25. Он также доступен в январском выпуске MSDN, Level 2 (Development Platform) CD4 \ODBC\X86 как часть ODBC 2.1 SDK. Очевидно есть обновление этих драйверов для файлов Access 2.5 на форуме MSACCESS CompuServe. Имейте в виду, что драйвер Access ODBC, поставляемый с некоторыми приложениями Microsoft (например, MS Office) могут использоваться только другими MS-приложениями. К сожалению, они могут сыграть с вами злую шутку: сначала заработать, а потом отказать в совершенно неподходящий момент! Поэтому не обращайте внимания (запретите себе обращать внимание!) на строчку "Access 2.0 for MS Office (*.mdb)" в списке драйверов ODBC Administrator. Вы можете установить новые ODBC драйверы с помощью ODBC Administrator в Панели Управления.
Добавление источника данных ODBC (Data Source): если у вас имеются все необходимые файлы, можете начинать. Представленный здесь пример использует драйвер Access 1.10, обеспечиваемый Delphi. Используя ODBC Administrator, установите источник данных для ваших файлов Access: щелчок на кнопке "Add" в окне "data sources" выведет диалог "Add Data Source", выберите Access Files (*.mdb) (или что-либо подходящее, в зависимости от установленных драйверов). В диалоге "ODBC Microsoft Access Setup" необходимо ввести имя в поле "Data Source Name". В данном примере мы используем "My Test". Введите описание "Data Source" в поле Description. Щелкните на "Select Database" для открытия диалога "Select Database". Перейдите в директорию, где хранятся ваши Access .MDB-файлы и выберите один. Мы выберем файл TEST.MDB в директории C:\DELPROJ\ACCESS. Нажмите OK в диалоге "Setup". Теперь в списке источников данных (Data Sources) должен появиться "My Test" (Access Files *.mdb). Нажмите Close для выхода из ODBC Administrator. Используя этот метод, вы можете установить и другие, необходимые вам, источники данных.
Настройка Borland Database Engine: загрузите теперь Borland Database Engine (BDE) Configuration Utility. На странице "Drivers" щелкните на кнопке New ODBC Driver. Имейте в виду, что это добавит драйвер Access в BDE и полностью отдельное управление дополнительно к драйверам Access в Windows, устанавливаемым при помощи ODBC Administrator. В открывшемся диалоге Add ODBC Driver в верхнем поле редактировании введите ACCESS (или что-то типа этого). BDE автоматически добавит на первое место ODBC_. В combobox, расположенном немного ниже, выберите Access Files (*.mdb). Выберите Data Source в следующем combobox (Default Data Source Name), это должен быть источник данных, который вы установили с помощью ODBC Administration Utility. Здесь можно не беспокоиться о вашем выборе, поскольку позднее это можно изменить (позже вы узнаете как это можно сделать). Нажмите OK. После установки драйвера BDE, вы можете использовать его более чем с одним источником данных ODBC, применяя различные псевдонимы (Alias) для каждого ODBC Data Source. Для установки псевдонима переключитесь на страницу "Aliases" и нажмите на кнопку "New Alias". В диалоговом окне "Add New Alias" введите необходимое имя псевдонима в поле "Alias Name". В нашем примере мы используем MY_TEST (не забывайте, что пробелы в псевдониме недопустимы). В combobox Alias Type выберите имя ODBC-драйвера, который вы только что создали (в нашем случае ODBC_ACCESS). Нажмите OK. Если вы имеете более одного ODBC Data Source, измените параметр ODBC DSN ("DSN" = "Data Source Name") в списке "Parameters" псевдонима на подходящий источник данных ODBC Data Source, как установлено в ODBC Administrator. Имейте в виду, что вы не должны ничего добавлять в параметр Path (путь), так как ODBC Data Source уже имеет эту информацию. Если вы добавляете параметр Path, убедитесь, что путь правильный, в противном случае ничего работать не будет! Теперь сохраните конфигурацию BDE, выбирая пункты меню File|Save, и выходите из Database Engine Configuration Utility.
В Delphi: Создайте новый проект и расположите на форме компоненты Table и DataSource из вкладки Data Access палитры компонентов. Затем из вкладки Data Controls выберите компонент DBGrid и также расположите его на форме. В Table, в Инспекторе Объектов, назначьте свойству DatabaseName псевдоним MY_TEST, установленный нами в BDE Configuration Utility. Теперь спуститесь ниже и раскройте список TableName. Вас попросят зарегистрироваться в базе данных Access MY_TEST. Обратите внимание, что если бюджет не установлен, то User Name и Password можно не заполнять, просто нажмите на кнопку OK. После некоторой паузы раскроется список, содержащий доступные таблицы для ODBC Data Source указанного псевдонима BDE. Выберите TEST. В DataSource, в Инспекторе Объектов, назначьте свойству DataSet таблицу Table1. В DBGrid, также в Инспекторе Объектов, назначьте свойству DataSource значение DataSource1. Возвратитесь к таблице, и в том же Инспекторе Объектов установите свойство Active в True. Данные из таблицы TEST отобразятся в табличной сетке. Это все! Одну вещь все-таки стоит упомянуть: если вы создаете приложение, использующее таблицы Access и запускаете его из-под Delphi IDE, то при попытке изменения данных в таблице(ах) вы получите ошибку. Если же вы запустите скомпилированный .EXE-файл вне Delphi (предварительно Delphi закрыв), то все будет ОК. Сообщения об ошибках ODBC, к несчастью, очень туманные и бывает достаточно трудно понять его источник в вашем приложении, в этом случае проверьте установку ODBC Administrator и BDE Configuration Utility, они также могут помочь понять источник ошибки. Для получения дополнительной информации обратитесь к ODBC 2.0 Programmer's Reference или SDK Guide от Microsoft Press (ISBN 1-55615-658-8, цена в США составляет $24.95). В этом документе вы получите исчерпывающую информацию о возможных ошибках при использовании Access-файлов посредством ODBC. Также здесь вы можете найти рапорты пользователей о найденных ошибках, в том числе и при использовании Delphi. Более того, я выяснил, что большинство описанных проблем возникает при неправильных настройках ODBC, т.е. те шаги, которые я описал выше. Надеюсь, что с развитием технологии доступа к базам данных такие сложности уйдут в прошлое. Кроме того, имейте в виду, что если вам необходимо создать новую таблицу Access 1.10, вы можете воспользоваться Database Desktop, включаемый в поставку Delphi.
Авторы данной технологии Ralph Friedman (CompuServe 100064,3102), Bob Swart и Chris Frizelle.
Взято из Советов по Delphi от Валентина Озерова
--------------------------------------------------------------------------------
Может кто-нибудь, предпочтительно из персонала Borland, ПОЖАЛУЙСТА, дать мне ПОЛНЫЙ рассказ о том, как с помощью Delphi и сопутствующего программного обеспечения получить доступ и работать с базами данных MS Access. Среди прочего, мне необходимо узнать...
Нижеследующая инструкция в точности повторяет ту технологию, с которой я работаю на данный момент, надеюсь, что это поможет.
Драйвер ODBC, предусмотренный для доступа к Access 2.0, разработан только для работы в пределах среды Microsoft Office. Для работы со связкой ODBC/Access в Delphi, вам необходим Microsoft ODBC Desktop Driver kit, part# 273-054-030, доступный через Microsoft Direct за $10.25US (если вы живете не в США, воспользуйтесь службой WINEXT). Он также доступен в январском выпуске MSDN, Level 2 (Development Platform) CD4 \ODBC\X86 как часть ODBC 2.1 SDK. Имейте в виду, что смена драйверов (в частности Desktop Drivers) может негативно сказаться на работе других приложений Microsoft. Для информации (и замечаний) обращайтесь в форум WINEXT.
Также вам необходимы следующие файлы ODBC:
Минимум:
ODBC.DLL 03.10.1994, Версия 2.00.1510
ODBCINST.DLL 03.10.1994, Версия 2.00.1510
ODBCINST.HLP 11.08.1993
ODBCADM.EXE 11.08.1993, Версия 1.02.3129
Рекомендуется:
ODBC.DLL 12.07.1994, Версия 2.10.2401
ODBCINST.DLL 12.07.1994, Версия 2.10.2401
ODBCINST.HLP 12.07.1994
ODBCADM.EXE 12.07.1994, Версия 2.10.2309
Нижеследующие шаги приведут вас к искомой цели:
1. Используя администратора ODBC, установите источник данных (datasource) для вашей базы данных. Не забудьте задать путь к вашему mdb-файлу. Для нашего примера создайте источник с именем MYDSN.
2. Загрузите утилиту BDE Configuration.
3. Выберите пункт "New Driver".
4. Назначьте драйверу имя (в нашем случае ODBC_MYDSN).
5. В выпадающем списке драйверов выберите "Microsoft Access Driver (*.mdb)
6. В выпадающем списке имен выберите MYDSN
7. Перейдите на страницу "Alias" (псевдонимы).
8. Выберите "New Alias" (новый псевдоним).
9. Введите MYDSN в поле имени.
10. Для Alias Type (тип псевдонима) выберите ODBC_MYDSN.
11. На форме Delphi разместите компоненты DataSource, Table, и DBGrid.
12. Установите DBGrid1.DataSource на DataSource1.
13. Установите DataSource1.DataSet на Table1.
14. Установите Table1.DatabaseName на MYDSN.
15. В свойстве TableName компонента Table1 щелкните на стрелочку "вниз" и вы увидите диалог "Login". Нажмите OK и после короткой паузы вы увидите список всех имен ваших таблиц. Выберите одно.
16. Установите свойство Active Table1 в True и данные вашей таблицы появятся в табличной сетке.
С появлением и продвижением микрософтом OLE DB и реализацией в Дельфи ADO (начиная с версии 5.0) работа с MS Access через ODBC перестала быть актуальной. За исключением особых случаев рекомендуется пользоваться именно ADO линейкой компонентов для связи с MS Access
Информация в локальных сетях, как правило, передается отдельными порциями, кусками, называемыми в различных источниках пакетами (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. Многоуровневая система вложения пакетов
Каждый следующий вкладываемый пакет может содержать собственную служебную информацию, располагающуюся как до данных (заголовок), так и после них (трейлер), причем ее назначение может быть различным. Безусловно, доля вспомогательной информации в пакетах при этом возрастает с каждым следующим уровнем, что снижает эффективную скорость передачи данных. Для увеличения этой скорости предпочтительнее, чтобы протоколы обмена были проще, и уровней этих протоколов было меньше. Иначе никакая скорость передачи битов не поможет, и быстрая сеть может передавать файл дольше, чем медленная сеть, которая пользуется более простым протоколом.
Обратный процесс последовательной распаковки данных приемником называется декапсуляцией пакетов.
Событие - это какое-либо действие, осуществляемое пользователем либо браузером. Например, когда мы щелкаем (кликаем) на ссылке - осуществляется событие, его перехватывает специальный обработчик и перенаправляет нас на нужную страницу; при наведении курсора (указателя мыши) на ссылку в строке состояния (обычно находится в нижней части окна браузера) отображается адрес, так как обработчик "наведения курсора на объект (в данном случае на ссылку)" помещает туда этот адрес и так далее...
а). 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.
На сегодняшний день музыкальные магазины online, наподобие Musikload[1], становятся все более распространенными и пользуются бешенной популярностью. В этой статье мы расскажем как можно читать мета-информацию mp3-файла средствами PHP, что поможет вам в создании каталога музыки. Это очень просто, поддержка базы данных не нужна.
Откуда знает MP3-Player, например Winamp информацию об исполнителе или названии композиции, которую он проигрывает? Может быть, он сам каким-то чудным образом узнает название песни и альбома? Нет, здесь нет никакого волшебства! Подобная информация содержится в самих файлах. Музыкальные файлы других форматов таких как WMA или Ogg Vorbis также содержат подобную информацию, но здесь речь пойдет о файлах в формате mp3.
Спецификация mp3 определяет способ хранения музыкальных данных, однако не предусматривает никакой возможности для сохранения метаданных композиции, таких как название и исполнитель. Чтобы обойти это ограничение был разработан стандарт ID3. Согласно этой спецификации, метаданные должны быть помещены в так называемые ID3-теги, которые независимо от используемого стандарта ID3, помещаются в конец или начало файла. ID3-теги версии 1 (ID3v1-Tags) представляют собой простейшую конструкцию, которая дописывается в конец файла. Ее объем не должен превышать 128 байт. Структура тега такова: после строкового значения “TAG» следует информация о названии (30 символов), исполнителе (30 символов), альбоме (30 символов), годе записи (четырехзначное число), комментарий (30 символов), жанр (1 байт). Тег с подобной структурой обозначается как ID3v1.0-Tag. В дополнение к этому существует еще стандарт ID3v1.1-Tag, который встречается значительно чаще, поскольку позволяет сохранять информацию о порядковом номере композиции в альбоме. Вследствие этого был урезан до 28 символов размер комментария. Сразу после комментария следует нуль-байт, а последующий байт содержит информации о номере трэка. На иллюстрации один и два видна структура обоих стандартов.
PEAR придет на помощь!
Для считывания информации из ID3v1 тегов, в библиотеку PEAR уже был включен пакет MP3_Id[3], который поможет Вам без проблем извлекать информацию из тега, или наоборот записывать. Если в файл отсутствует ID3-тег, вы можете его создать. Листинг 1 показывает как можно считывать информацию из тегов. Создается объект класса MP3_ID, считывается файл, а затем метод getTag() извлекает данные, которые помещаются для дальнейшей обработки в отдельные поля объект. Листинг 2 показывает результат действия программы листинга 1. Общий обзор доступных полей вы найдете в документации по пакету на домашней странице PEAR.
Листинг 1:
Листинг 2:
Листинг 3 показывает как просто можно изменять содержимое ID3-тегов и создавать их. Сначала, как это было показано в Листинге 1, создаем объект класса MP3_ID, считываем файл, а с помощью метода setTag($fieldname, $value) помещаем в тег нужную информацию. Хотите удалить все теги? Тогда посмотрите на листинг 4, где показано как можно сделать это. Для удаления тегов используется метод remove(), а остальное вы уже знаете. Необходимо дополнить, что MP3_Id обладает другими полезными функциями, которые вам позволят перенести содержимое тега из одного файла в другой или сформировать массив, содержащий все музыкальные направления. Для получения дополнительной информации смотрите документацию.
Listing 3:
Listing 4:
Используем PECL
В конце лета 2004 года появилось расширение PHP ext/id3[7]. Разрабатывается в рамках PECL[6]. В отличие от MP3_ID эта библиотека написана не на PHP, а на C, поэтому она должно работать несколько быстрее. Однако библиотека не входит в стандартный комплект PHP-исходников, к тому же на сегодняшний день отсутствует стабильная версия, хотя функции отвечающие за чтение и запись ID3-тегов считаются стабильными.
Если вы хотите использовать именно это расширение, для установки необходимо воспользоваться либо PEAR-installer, либо откомпилировать php, включив поддержку данного расширения. Если вы используете WINDOWS, существует возможность скачать уже откомпилированную DLL для версии php 5.0 или 5.01 с сайта PHP-Snapshot[9], поместить ее в каталог с расширениями php (например c:phpext), подключить через php.ini. Чтобы воспользоваться расширением, вы должны иметь PHP 4.3 или более позднюю версию, поскольку библиотека использует Streams-API.
Само собой разумеется, библиотека позволяет изменять содержимое ID3-тегов. Для этого вам не нужно ничего, кроме массива, представленного в листинге 6, и функции id3_set_tag(). В качестве первого параметра функция принимает имя изменяемого mp-3 файла, а в качестве второго - массив с необходимыми данными. Третий параметр необязателен и представляет собой константу, указывающую версию ID3-тега. В существующей версии библиотеки функция id3_set_tag() может работать только с тегами версии 1.0 или 1.1. Листинг 7 содержит необходимый php-код. В дополнение к этому, листинг 8 показывает как с помощью функции id3_remove_tag можно удалить существующий ID3-тег.
Ext/id3 содержит еще несколько полезных функций, которые позволяют определить версию ID3-тега (id3_get_version) или манипулируют со списком музыкальных направлений и их id, представленных в виде целого числа типа integer. Надо сказать, что данное число мало подходит для указания музыкального направления.
Listing 5:
Listing 6:
Listing 7:
Следующее поколение
Несмотря на то, что с помощь ID3v1-тегов уже можно сохранять важнейшую информацию о содержимом mp3-файла, уже проявляются ограничения версий 1.0 и 1.1:
из-за фиксированного размера тега ограничен объем сохраняемой информации
ограничено количество сохраняемых атрибутов
Как мы видим, расширить объем пространства, отведенный под ID3v1 теги нельзя, Существую трудности с сохранением информации о названии композиции, исполнителе, альбоме, комментарии, если размер данных превышает 30 символов. Допустим, вам нужно указать название The Hitchhiker's Guide to the Galaxy, используя стандарт ID3v1, вы можете сохранить лишь The Hitchhiker's Guide to. Та же ситуации наблюдается с указанием музыкального направления. Для этого выделяется только один байт, вследствие этого количество музыкальных направлений не может превышать 256. Наверное, сегодня этого достаточно, но кто знает, сколько в будущем появится еще музыкальных направлений.
Чтобы преодолеть указанные ограничения был введены ID3-теги версии 2[2], или короче ID3v2. ID3v2-теги записываются в начало файла, собственно перед самими аудио данными. Информация организована в отдельные единицы, которые обозначаются как фреймы. ID3v2 - это формат-контейнер, то есть, существует возможность при изменении тега вводить новые фреймы. Из этого следует, что ID3v2 может содержать значительно больше информации, чем ID3v1. Это может быть информация об авторских правах, битрейте, (BMP) или, наконец, полный текст песни или изображения. В дополнение к этому можно по желанию добавлять новые фреймы. Вот важнейшие достоинства данного формата:
Никаких ограничений на объем сохраняемой информации
Гибкость и расширяемость
Возможность сжатия содержимого тегов
Поддержка Unicode
Возможность хранить бинарные данные, например изображения и файлы.
Из-за расширенных возможностей ID3v2-теги, несколько труднее поддаются считыванию, чем ID3v1-теги. Хорошая новость состоит в том, что ext/id3 уже позволяет извлекать важнейшую информацию. Если вы исполните код, помещенный в листинг 9, вы получите тот же результат, что и в листинге 10. Проделав это, вы сможете убедиться, что объем выводимых данных значительно шире, чем тот, что показан в листингах 5 и 6.
Каждый фрейм ID3v2-тега обладает уникальным ID. Ext/id3 содержит две функции, которые позволяют узнать содержимое фрейма. Это id3_get_frame_short() и id3_get_frame_long_name(). В качестве параметра они принимают id фрейма и возвращают его описание.
В будущих версиях ext/id3 будет содержать другие полезные функции, которые позволят считывать или записывать фреймы, соответствующие спецификации ID3.
Листинг 8:
Listing 9:
Дополнительная информация
Прежде чем вы организуете бизнес, связанный с продажей музыкальных композиций online, мы вам расскажем еще о нескольких полезных возможностях библиотеки MP3_Id. С помощью нее можно не только считывать информацию ID3- тегов, она позволяет получить некоторую интересную информацию о самом mp3-файле. Речь идет о битрейте, длительности звучания и других полезных свойствах. Подобные сведения можно получить при помощи метода study(), а дальше посредством метода getTag(), можно выбирать необходимые данные. Листинг 12 показывает как это работает. Результат работы программы показан в листинге 13. К сожалению, эти возможности недостаточно документированы, т.е. трудно разобраться какой атрибут можно считать при помощи getTag() или изменить посредство setTag(). В этом случае необходимо изучить код модуля MP3/Id.php.
Listing 10:
Listing 11:
Listing 12:
Listing 13:
Выводы
В этой статье мы рассмотрели существующие возможности извлечения информации из mp-3 файлов средствами PHP. Обе библиотеки (MP3_Id и id3) легки в использовании и содержать необходимые функции. Одна библиотека написана на PHP, другая на C. Выбор того или иного варианта определяется вашими предпочтениями и возможностями хостинга.
Авторы
Карстен Луке изучает информатику в высшей школе Бранденбурга. Совместно со Стефаном Шмидтом разработывает расширение id3. Вы можете связаться с ним по e-mail ( luckec@php.net ) или посетить его сайт ( www.tool-gerade.de ) Стефан Шмидт - разработчик веб-приложений фирмы 1&1 Internet AG, активно учавствует в развити PEAR и PECL. Вы можете связаться с ним по e-mail ( schst@php.net )
Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах. На практике это означает, что потоки исполняют код и манипулируют данными в адресном пространстве процесса. Если два или более потока выполняются внутри одного процесса, они делят одно адресное пространство.
Любой поток (thread) состоит из двух компонентов:
объекта ядра, через который ОС управляет потоком. Там же хранится статистическая информация о потоке.
Стека потока, который содержит параметры всех функций и локальные переменные, необходимые потоку для выполнения кода.
Потоки могут выполнять один и тот же код, манипулировать одними и теми же данными, а также совместно использовать описатели объектов ядра, поскольку таблица описателей создается не в отдельных потоках, а в процессах.
Потоки используют намного меньше ресурсов системы, чем процессы, поэтому все задачи, требующие параллельного выполнения нескольких подзадач, стоит решать по возможности с помощью потоков, не прибегая к созданию нескольких процессов.
Обычная структура многопоточного приложения рассчитана на одновременное исполнение нескольких подзадач. Однако стоит помнить, что, создавая многопоточное приложение, нам придется заботиться о сохранности и ликвидности, общих для всех потоков, данных.
Создание потока.
Первичный поток, который присутствует в программе, начинает свое выполнение с главной функции потока типа WinMain.
Для создания вторичного потока необходимо создать и для него входную функцию, которая выглядит примерно так:
Имя у функции вторичного потока, в отличии от первичного, может быть любым однако, при наличии нескольких разных потоков, назвать функции необходимо по-разному, иначе система создаст разные реализации одной и той же функции.
Когда поток закончит свое исполнение, он вернет управление системе, память, отведенная под его стек, будет освобождена, а счетчик пользователей его объекта ядра "поток" уменьшится на 1. Когда счетчик обнулится, этот объект ядра будет разрушен.
Для создания своего потока необходимо использовать функцию CreateThread:
При каждом вызове этой функции система создает объект ядра (поток). Это не сам поток, а компактная структура данных, которая используется операционной системой для управления потоком и хранит статистическую информацию о потоке.
Система выделяет память под стек потока из адресного пространства процесса. Новый поток выполняется в контексте того же процесса, что и родительский поток. Поэтому он получает доступ ко всем описателям объектов ядра, всей памяти и стекам всех потоков в процессе. За счет этого потоки в рамках одного процесса могут легко взаимодействовать друг с другом.
CreateThread - это Windows-функция, создающая поток. Если вы пишете код на С/С++ не вызывайте ее. Вместо нее Вы должны использовать _beginthreadex из библиотеки Visual C++. Почему это так важно в наших следующих выпусках.
Параметры функции CreateThread.
LpThreadAttributes - является указателем на структуру LPSECURITY_ATTRIBUTES. Для присвоения атрибутов защиты по умолчанию, передавайте в этом параметре NULL.
DwStackSize - параметр определяет размер стека, выделяемый для потока из общего адресного пространства процесса. При передаче 0 - размер устанавливается в значение по умолчанию.
LpStartAddress - указатель на адрес входной функции потока.
LpParameter - параметр, который будет передан внутрь функции потока.
DwCreationFlags - принимает одно из двух значений: 0 - исполнение начинается немедленно, или CREATE_SUSPENDED - исполнение приостанавливается до последующих указаний.
LpThreadId - Адрес переменной типа DWORD в который функция возвращает идентификатор, приписанный системой новому потоку.
Завершение потока
Поток можно завершит четырьмя способами:
функция потока возвращает управление (рекомендуемо);
поток самоуничтожается вызовом функции ExitThread;
другой поток процесса вызывает функцию TerminateThread;
завершается процесс, содержащий данный поток.
Все способы , за исключением рекомендуемого, являются нежелательными и должны использоваться только в форс-мажорных обстоятельствах.
Функция потока, возвращая управление, гарантирует корректную очистку всех ресурсов, принадлежащих данному потоку. При этом:
любые С++ объекты, созданные данным потоком, уничтожаются соответствующими деструкторами;
система корректно освобождает память, которую занимал стек потока;
система устанавливает код завершения данного потока. Его функция и возвращает;
счетчик пользователей данного объекта ядра (поток) уменьшается на 1.
При желании немедленно завершить поток изнутри используют функцию ExitThread(DWORD dwExitCode).
При этом освобождаются все ресурсы ОС, выделенные данному потоку, но С С++ ресурсы (например, объекты классов С++) не очищаются. Именно поэтому не рекомендовано завершать поток, используя эту функцию.
Если же вы ее использовали, то кодом возврата потока будет тот параметр, который вы передадите в данную функцию.
Как и для CreateThread для библиотеки Visual C++ существует ее аналог _endthreadex, который и стоит использовать. Об причинах в следующем выпуске.
Если появилась необходимость уничтожить поток снаружи, то это моет сделать функция TeminateThread.
Эта функция уменьшит счетчик пользователей объекта ядра (поток) на 1, однако при этом не разрушит и не очистит стек потока. Стек будет существовать, пока не завершится процесс, которому принадлежит поток. При задачах, постоянно создающих и уничтожающих потоки, это приводит к потере памяти внутри процесса.
При завершении процесса происходит следующее.
Завершение потока происходит принудительно. Деструкторы объектов не вызываются, и т.д. и т.д.
При завершении потока по такой причине, связанный с ним объект ядра (поток) не освобождается до тех пор, пока не будут закрыты все внешние ссылки на этот объект.
Поисковая оптимизация - это комплекс работ над сайтом и внешними факторами для достижения наилучших позиций в поисковых системах в соответствии с выбранными ключевыми словами. Этот способ оптимизации позволяет достигать высоких позиций в результатах выдачи поисковых машин по профильным запросам (ключевым словам) и тем самым привлекать огромную часть целевых посетителей.
В настоящий момент единственным путём завоевать Интернет-просторы, является оптимизация и продвижение сайта в поисковых системах. С каждым годом число пользователей Интернета, а, следовательно, поисковых систем растет. А это значит, что поисковая оптимизация приносит все больше и больше выгоды владельцам сайта. Согласно статистике, около 85% пользователей ищут информацию при помощи поисковых машин, которые обеспечивают от 70% до 85% от общей посещаемости ресурса.
Основные этапы оптимизации сайта и поискового продвижения:
* анализ ресурса;
* составление семантического ядра для поисковой оптимизации;
* оптимизация сайта: тексты, навигация, код;
* поисковое продвижение сайта: регистрация сайта в каталогах, на досках объявлений и форумах, работа со ссылочным ранжированием.
Поисковую оптимизацию можно разделить на внутреннюю и внешнюю.
Внутренняя оптимизация сайта направлена на работу с самим сайтом. К ней относится:
1. Составление семантического ядра сайта.
Семантическое ядро представляет собой совокупность запросов (ключевых слов), смыслу которых отвечает интернет-ресурс. Семантическое ядро создается с учетом специфики сайта из наиболее распространенных и соответствующих ключевых слов. По такому списку ключевых слов отслеживается продвижение сайта.
Правильно подобранные ключевые слова станут эффективным оружием в конкурентной борьбе. Есть несколько рекомендаций по использованию ключевых слов на страницах интернет-ресурсов.
Советы по использованию ключевых слов:
* Всегда используйте более одного слова при выборе ключевых фраз. Исследования показали, что большинство людей вводят в строку поиска фразу, состоящую из 2-х слов и более.
* Избегайте самых популярных ключевых слов, потому что Вашему сайту придется конкурировать с миллионом других подобных страниц, среди которых те, что принадлежат более мощным компаниям.
* Оптимальная частотность ключевых слов - 5%. Использование большего количества ключевых фраз может превратить ваш документ в спам.
2. Оптимизация страниц сайта.
В нее входят работы с html-кодом и текстами (контентом) страниц. При оптимизации html-кода проводится правка непосредственно html-кода, коррекция META-тегов, заголовков, описаний страниц сайта, выделение нужных частей страницы специальными тегами. Все тексты страниц анализируются и корректируются в соответствии с ключевыми словами.
Основные факторы ранжирования, на которые надо обратить внимание:
* Теги title - заголовки страниц сайта, наиболее важный фактор, на который следует обратить внимание. В заголовки страниц необходимо прописывать слова, по которым вы планируете провести оптимизацию сайта, но не следует забывать о том, что текст, содержащийся в заголовке страницы, будет выдаваться в результатах поиска. Следовательно, заголовок страницы должен быть информативными и привлекательно выглядеть, ведь с большей вероятностью пользователь выберет именно такое описание страницы. Распространенная ошибка - использование одного заголовка для всех страниц сайта. Для каждой страницы заголовок должен разрабатываться отдельно, в соответствии с содержанием страницы.
*
* Тег meta name="description" content="описание страницы" - практически никак не влияет на ранжирование сайта, однако это описание страницы будет выдаваться, если ваш сайт будет найден по ссылке, поэтому всё же стоит составить грамотное описание страницы и включить его в данный тег.
* Теги заголовков h1-h6 - играют очень большую роль при ранжировании сайта. Рекомендуется включать ключевые слова в данные теги. Также можно оформлять данные теги с помощью стилей CSS, но в пределах разумного, т.е. заголовок h1 должен быть основным заголовком страницы, h2 - подзаголовком и т.д. При попытке включить весь текст на странице в данный тег, ваш сайт может быть вообще исключен из результатов поиска, так что рекомендуем вам пользоваться данными тегами осторожно и не злоупотреблять ими.
* Теги акцентирования b, i и им подобные - рекомендуется выделять ключевые слова на странице данными тегами, это может дать преимущество при ранжировании сайта.
* Плотность ключевых слов на странице - отношение количества ключевых слов и словосочетаний к полному текстовому объему страницы. Рекомендуемой плотностью является, по разным данным, от 5% до 7%.
3. Оптимизация структуры сайта.
Изменение внутренних ссылок на страницы, создание карты сайта, для того чтобы поисковый робот смог проиндексировать все страницы. После таких работ поисковым роботам будет проще и удобнее работать со страницами, что ускорит их индексацию.
Рекомендации по структуре сайта:
* Используйте текстовые ссылки на все страницы сайта с необходимыми ключевыми словами, используйте прямые ссылки вида: , поисковые системы очень хорошо распознают такие ссылки, использование сложных скриптов, таких как Java, PHP и т.п. для формирования ссылок лучше не используйте.
* При наличии большого количества страниц на сайте, сделайте карту сайта, можно даже разбить ее на несколько страниц так, чтобы одна страница не содержала больше 50 исходящих ссылок (это затрудняет работу поискового робота).
* Следуйте "правилу трех кликов", т.е. все страницы сайта должны быть доступны пользователю на расстоянии 3-х кликов от главной страницы.
* Старайтесь не использовать на страницах сайта большое количество flash и графики, страница не должна очень много весить.
К внешней оптимизации относятся действия по повышению "дружественности" к поисковым системам и авторитетности (популярности) интернет-ресурса. Чтобы увеличить популярность сайта нужно учесть такие факторы как:
1. Ссылки с сайтов с большим тИЦ и PageRank.
Такие ссылки являются качественными и обладают большим весом, что влияет на позиции сайта в результатах поиска.
2. Тексты описания ссылок.
Текст ссылки, содержащий ключевые слова, воспринимается поисковой системой как дополнительная рекомендация, подтверждающая соответствие поисковому запросу, что влияет на ранжирование сайта.
3. Ссылки на тематических сайтах.
Кроме текста ссылок поисковые роботы учитывают общее информационное содержимое ссылающейся страницы сайта и при схожести тематик дают таким ссылкам больший вес.
4. Односторонние ссылки.
Поисковые системы стараются отслеживать взаимные ссылки, поэтому отдают предпочтение односторонним ссылкам, считая их более подлинными и ценными.
5. Избегание "плохих" ссылок.
С тех пор как увеличение ссылочности стала одним из важных факторов ранжирования, число сайтов "каталогов ссылок" возросло. Поисковые системы негативно относятся к многочисленным каталогам сайтов и стараются обесценить такие ссылки или не учитывать их совсем.
Часто встречающаяся ошибка при работе с сессией - поздний старт. Когда данные в браузер уже начали отправляться и вызов session_start() приводит к ошибке "headers already sent". На этом спотыкаются многие начинающие (и не только) программисты PHP.
Для понимания проблемы надо немного разбираться в работе протокола HTTP. Текущая версия протокола (1.1) описана в документе RFC2616.
Протокол работает по принципу "запрос - ответ". Браузер пользователя посылает запрос на сервер. Тот, в свою очередь, посылает браузеру ответ. И запрос, и ответ состоят из заголовка и следующих за ним данных (тело). Т.е. если данные уже начали отсылаться, то что-либо добавить в заголовок уже возможности нет. Куки как раз передаются в заголовке HTTP запросов и ответов.
Да же если Вы поместите блок , содержащий session_start() в самое начало файла, но перед ним будет пробел или перевод строки, то это тоже приведет к ошибке. Никаких символов перед блоком быть не должно!
Что же делать, если решение, использовать сессию или нет, принимается не в самом начале программы и перед ним возможен какой-либо вывод?
Выход простой - использовать буферизацию. В PHP буферизацией управляют функции начинающиеся на "ob_" (output bufferering). В начале программы (до любого возможного вывода) следует поставить вызов ob_start(), а перед завершением программы (хотя бы после старта сессии) - ob_end_flush().
Кстати, при работе непосредственно с Куки и заголовками HTTP возникают те же самые проблемы и решаются они аналогично.
Вернемся к Куки и сессии.Сессия имеет имя, используемое как в Куки, так и при передаче идентификатора сессии в параметрах URL. По умолчанию, это имя - "PHPSESSID". Его можно поменять на другое имя, глобально для всего сервера, через php.ini (session.name). Так же можно изменить его только для данной программы, в процессе выполнения, функцией session_name().
Сразу предостерегу от возможных ошибок: параметры сессии можно менять только до ее старта.
Кроме имени, параметрами сессии являются: время жизни и параметры Куки.
Время жизни сессии - это время неактивности сессии, по истечении которого сессия может быть удалена сборщиком мусора и пользователь, зайдя на сайт еще раз, получит новый идентификатор сессии и, соответственно, новую сессию. Задается время жизни в php.ini (session.lifetime). При использовании собственных обработчиков этот параметр php.ini можно игнорировать и использовать свое значение времени жизни.
Куки может иметь следующие необязательные параметры: время жизни, путь URL, DNS-домен, признак секретности. Я их перечислил в порядке "уменьшения обязательности". Т.е., нельзя указать домен, не указав время жизни и путь.
Смысл параметров следующий:
* Время жизни.
Это рекомендованное время хранения Куки в браузере пользователя. Если время равно нолю, то Куки удаляется после закрытия браузера (или во время его следующего запуска) и называется это "хранение на время текущей сессии". По умолчанию, время жизни равно нулю.
* Путь URL.
Если запрашиваемый путь начинается с этого значения, то данное Куки посылается в запросе. Это позволяет иметь на одном сервере несколько независимых программ, работающих с собственными сессиями. Такие программы должны находиться в разных директориях и директория одной программы не может быть вложена в директорию другой программы. Например, "/a/" и "/b/" - могут иметь независимый друг от друга набор Куки, а "/a/" и "/a/b/" - нет (все Куки для пути "/a/" будут посылаться и при запросе пути "/a/b/"). По умолчанию, используется путь "/".
* DNS-домен.
Домены DNS - это имена, используемые в Интернете. Домены образуют древовидную иерархию. Например, в домене com есть домен shelek.com, а в нем есть домены club.shelek.com и forum.shelek.com.
Если указать в Куки домен shelek.com, то браузер будет посылать это Куки в запросах к shelek.com, club.shelek.com и forum.shelek.com. Если же указать, forum.shelek.com, то это Куки посылаться будет только при запросах в домены, начинающиеся с этого имени и мешать домену club.shelek.com не будет. По умолчанию, используется домен, на который браузером был послан запрос. Т.е., если нет особой необходимости, то этот параметр менять не нужно.
* Признак секретности.
Если установить этот признак, то данное Куки будет посылаться только в запросах по защищенному каналу (SSL, TLS, IPsec). Напомню, что для того, чтобы можно было устанавливать этот параметр, нужно задать все предыдущие. В том числе и домен. Его текущее значение можно взять из $_SERVER['SERVER_NAME'].
Поиск
