Сеть всегда объединяет несколько абонентов, каждый из которых имеет право передавать свои пакеты. Но, как уже отмечалось, по одному кабелю одновременно передавать два (или более) пакета нельзя, иначе может возникнуть конфликт (коллизия), который приведет к искажению либо потере обоих пакетов (или всех пакетов, участвующих в конфликте). Значит, надо каким-то образом установить очередность доступа к сети (захвата сети) всеми абонентами, желающими передавать. Это относится, прежде всего, к сетям с топологиями шина и кольцо. Точно так же при топологии звезда необходимо установить очередность передачи пакетов периферийными абонентами, иначе центральный абонент просто не сможет справиться с их обработкой.
В сети обязательно применяется тот или иной метод управления обменом (метод доступа, метод арбитража), разрешающий или предотвращающий конфликты между абонентами. От эффективности работы выбранного метода управления обменом зависит очень многое: скорость обмена информацией между компьютерами, нагрузочная способность сети (способность работать с различными интенсивностями обмена), время реакции сети на внешние события и т.д. Метод управления – это один из важнейших параметров сети.
Тип метода управления обменом во многом определяется особенностями топологии сети. Но в то же время он не привязан жестко к топологии, как нередко принято считать.
Методы управления обменом в локальных сетях делятся на две группы:
* Централизованные методы, в которых все управление обменом сосредоточено в одном месте. Недостатки таких методов: неустойчивость к отказам центра, малая гибкость управления (центр обычно не может оперативно реагировать на все события в сети). Достоинство централизованных методов – отсутствие конфликтов, так как центр всегда предоставляет право на передачу только одному абоненту, и ему не с кем конфликтовать.
* Децентрализованные методы, в которых отсутствует центр управления. Всеми вопросами управления, в том числе предотвращением, обнаружением и разрешением конфликтов, занимаются все абоненты сети. Главные достоинства децентрализованных методов: высокая устойчивость к отказам и большая гибкость. Однако в данном случае возможны конфликты, которые надо разрешать.
Существует и другое деление методов управления обменом, относящееся, главным образом, к децентрализованным методам:
* Детерминированные методы определяют четкие правила, по которым чередуются захватывающие сеть абоненты. Абоненты имеют определенную систему приоритетов, причем приоритеты эти различны для всех абонентов. При этом, как правило, конфликты полностью исключены (или маловероятны), но некоторые абоненты могут дожидаться своей очереди на передачу слишком долго. К детерминированным методам относится, например, маркерный доступ (сети Token-Ring, FDDI), при котором право передачи передается по эстафете от абонента к абоненту.
* Случайные методы подразумевают случайное чередование передающих абонентов. При этом возможность конфликтов подразумевается, но предлагаются способы их разрешения. Случайные методы значительно хуже (по сравнению с детерминированными) работают при больших информационных потоках в сети (при большом трафике сети) и не гарантируют абоненту величину времени доступа. В то же время они обычно более устойчивы к отказам сетевого оборудования и более эффективно используют сеть при малой интенсивности обмена. Пример случайного метода – CSMA/CD (сеть Ethernet).
Для трех основных топологий характерны три наиболее типичных метода управления обменом.
Управление обменом в сети с топологией звезда
Для топологии звезда лучше всего подходит централизованный метод управления. Это связано с тем, что все информационные потоки проходят через центр, и именно этому центру логично доверить управление обменом в сети. Причем не так важно, что находится в центре звезды: компьютер (центральный абонент), как на рис. 1.6, или же специальный концентратор, управляющий обменом, но сам не участвующий в нем. В данном случае речь идет уже не о пассивной звезде (рис. 1.11), а о некой промежуточной ситуации, когда центр не является полноценным абонентом, но управляет обменом. Это, к примеру, реализовано в сети 100VG-AnyLAN.
Самый простейший централизованный метод состоит в следующем.
Периферийные абоненты, желающие передать свой пакет (или, как еще говорят, имеющие заявки на передачу), посылают центру свои запросы (управляющие пакеты или специальные сигналы). Центр же предоставляет им право передачи пакета в порядке очередности, например, по их физическому расположению в звезде по часовой стрелке. После окончания передачи пакета каким-то абонентом право передавать получит следующий по порядку (по часовой стрелке) абонент, имеющий заявку на передачу (рис. 4.8). Например, если передает второй абонент, то после него имеет право на передачу третий. Если же третьему абоненту не надо передавать, то право на передачу переходит к четвертому и т.д.
Централизованный метод управления обменом в сети с топологией звезда
Рис. 4.8. Централизованный метод управления обменом в сети с топологией звезда
В этом случае говорят, что абоненты имеют географические приоритеты (по их физическому расположению). В каждый конкретный момент наивысшим приоритетом обладает следующий по порядку абонент, но в пределах полного цикла опроса ни один из абонентов не имеет никаких преимуществ перед другими. Никому не придется ждать своей очереди слишком долго. Максимальная величина времени доступа для любого абонента в этом случае будет равна суммарному времени передачи пакетов всех абонентов сети кроме данного. Для топологии, показанной на рис. 4.8, она составит четыре длительности пакета. Никаких столкновений пакетов при этом методе в принципе быть не может, так как все решения о доступе принимаются в одном месте.
Рассмотренный метод управления можно назвать методом с пассивным центром, так как центр пассивно прослушивает всех абонентов. Возможен и другой принцип реализации централизованного управления (его можно назвать методом с активным центром).
В этом случае центр посылает запросы о готовности передавать (управляющие пакеты или специальные сигналы) по очереди всем периферийным абонентам. Тот периферийный абонент, который хочет передавать (первый из опрошенных) посылает ответ (или же сразу начинает свою передачу). В дальнейшем центр проводит сеанс обмена именно с ним. После окончания этого сеанса центральный абонент продолжает опрос периферийных абонентов по кругу (как на рис. 4.8). Если желает передавать центральный абонент, он передает вне очереди.
Как в первом, так и во втором случае никаких конфликтов быть не может (решение принимает единый центр, которому не с кем конфликтовать). Если все абоненты активны, и заявки на передачу поступают интенсивно, то все они будут передавать строго по очереди. Но центр должен быть исключительно надежен, иначе будет парализован весь обмен. Механизм управления не слишком гибок, так как центр работает по жестко заданному алгоритму. К тому же скорость управления невысока. Ведь даже в случае, когда передает только один абонент, ему все равно приходится ждать после каждого переданного пакета, пока центр опросит всех остальных абонентов.
Как правило, централизованные методы управления применяются в небольших сетях (с числом абонентов не более чем несколько десятков). В случае больших сетей нагрузка по управлению обменом на центр существенно возрастает.
Управление обменом в сети с топологией шина
При топологии шина также возможно централизованное управление. При этом один из абонентов ("центральный") посылает по шине всем остальным ("периферийным") запросы (управляющие пакеты), выясняя, кто из них хочет передать, затем разрешает передачу одному из абонентов. Абонент, получивший право на передачу, по той же шине передает свой информационный пакет тому абоненту, которому хочет. А после окончания передачи передававший абонент все по той же шине сообщает "центру", что он закончил передачу (управляющим пакетом), и "центр" снова начинает опрос (рис. 4.9).
Централизованное управление в сети с топологией шина
Рис. 4.9. Централизованное управление в сети с топологией шина
Преимущества и недостатки такого управления – те же самые, что и в случае централизованно управляемой звезды. Единственное отличие состоит в том, что центр здесь не пересылает информацию от одного абонента к другому, как в топологии активная звезда, а только управляет обменом.
Гораздо чаще в шине используется децентрализованное случайное управление, так как сетевые адаптеры всех абонентов в данном случае одинаковы, и именно этот метод наиболее органично подходит шине. При выборе децентрализованного управления все абоненты имеют равные права доступа к сети, то есть особенности топологии совпадают с особенностями метода управления. Решение о том, когда можно передавать свой пакет, принимается каждым абонентом на месте, исходя только из анализа состояния сети. В данном случае возникает конкуренция между абонентами за захват сети, и, следовательно, возможны конфликты между ними и искажения передаваемой информации из-за наложения пакетов.
Существует множество алгоритмов доступа или, как еще говорят, сценариев доступа, порой очень сложных. Их выбор зависит от скорости передачи в сети, длины шины, загруженности сети (интенсивности обмена или трафика сети), используемого кода передачи.
Иногда для управления доступом к шине применяется дополнительная линия связи, что позволяет упростить аппаратуру контроллеров и методы доступа, но заметно увеличивает стоимость сети за счет удвоения длины кабеля и количества приемопередатчиков. Поэтому данное решение не получило широкого распространения.
Суть всех случайных методов управления обменом довольно проста.
Если сеть свободна (то есть никто не передает своих пакетов), то абонент, желающий передавать, сразу начинает свою передачу. Время доступа в этом случае равно нулю.
Если же в момент возникновения у абонента заявки на передачу сеть занята, то абонент, желающий передавать, ждет освобождения сети. В противном случае исказятся и пропадут оба пакета. После освобождения сети абонент, желающий передавать, начинает свою передачу.
Возникновение конфликтных ситуаций (столкновений пакетов, коллизий), в результате которых передаваемая информация искажается, возможно в двух случаях.
* При одновременном начале передачи двумя или более абонентами, когда сеть свободна (рис. 4.10). Это ситуация довольно редкая, но все-таки вполне возможная.
* При одновременном начале передачи двумя или более абонентами сразу после освобождения сети (рис. 4.11). Это ситуация наиболее типична, так как за время передачи пакета одним абонентом вполне может возникнуть несколько новых заявок на передачу у других абонентов.
Существующие случайные методы управления обменом (арбитража) различаются тем, как они предотвращают возможные конфликты или же разрешают уже возникшие. Ни один конфликт не должен нарушать обмен, все абоненты должны, в конце концов, передать свои пакеты.
В процессе развития локальных сетей было разработано несколько разновидностей случайных методов управления обменом.
Коллизии в случае начала передачи при свободной сети
Рис. 4.10. Коллизии в случае начала передачи при свободной сети
Коллизии в случае начала передачи после освобождения сети
Рис. 4.11. Коллизии в случае начала передачи после освобождения сети
Например, был предложен метод, при котором не все передающие абоненты распознают коллизию, а только те, которые имеют меньшие приоритеты. Абонент с максимальным приоритетом из всех, начавших передачу, закончит передачу своего пакета без ошибок. Остальные, обнаружив коллизию, прекратят свою передачу и будут ждать освобождения сети для новой попытки. Для контроля коллизии каждый передающий абонент производит побитное сравнение передаваемой им в сеть информации и данных, присутствующих в сети. Побеждает тот абонент, заголовок пакета которого дольше других не искажается от коллизии. Этот метод, называемый децентрализованным кодовым приоритетным методом, отличается низким быстродействием и сложностью реализации.
При другом методе управления обменом каждый абонент начинает свою передачу после освобождения сети не сразу, а, выдержав свою, строго индивидуальную задержку, что предотвращает коллизии после освобождения сети и тем самым сводит к минимуму общее количество коллизий. Максимальным приоритетом в этом случае будет обладать абонент с минимальной задержкой. Столкновения пакетов возможны только тогда, когда два и более абонентов захотели передавать одновременно при свободной сети. Этот метод, называемый децентрализованным временным приоритетным методом, хорошо работает только в небольших сетях, так как каждому абоненту нужно обеспечить свою индивидуальную задержку.
В обоих случаях имеется система приоритетов, все же данные методы относятся к случайным, так как исход конкуренции невозможно предсказать. Случайные приоритетные методы ставят абонентов в неравные условия при большой интенсивности обмена по сети, так как высокоприоритетные абоненты могут надолго заблокировать сеть для низкоприоритетных абонентов.
[pagebreak]
Чаще всего система приоритетов в методе управления обменом в шине отсутствует полностью. Именно так работает наиболее распространенный стандартный метод управления обменом CSMA/CD (Carrier Sense Multiple Access with Collision Detection – множественный доступ с контролем несущей и обнаружением коллизий), используемый в сети Ethernet. Его главное достоинство в том, что все абоненты полностью равноправны, и ни один из них не может надолго заблокировать обмен другому (как в случае наличия приоритетов). В этом методе коллизии не предотвращаются, а разрешаются.
Суть метода состоит в том, что абонент начинает передавать сразу, как только он выяснит, что сеть свободна. Если возникают коллизии, то они обнаруживаются всеми передающими абонентами. После чего все абоненты прекращают свою передачу и возобновляют попытку начать новую передачу пакета через временной интервал, длительность которого выбирается случайным образом. Поэтому повторные коллизии маловероятны.
Еще один распространенный метод случайного доступа – CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance – множественный доступ с контролем несущей и избежанием коллизий) применяющийся, например, в сети Apple LocalTalk. Абонент, желающий передавать и обнаруживший освобождение сети, передает сначала короткий управляющий пакет запроса на передачу. Затем он заданное время ждет ответного короткого управляющего пакета подтверждения запроса от абонента-приемника. Если ответа нет, передача откладывается. Если ответ получен, передается пакет. Коллизии полностью не устраняются, но в основном сталкиваются управляющие пакеты. Столкновения информационных пакетов выявляются на более высоких уровнях протокола.
Подобные методы будут хорошо работать только при не слишком большой интенсивности обмена по сети. Считается, что приемлемое качество связи обеспечивается при нагрузке не выше 30—40% (то есть когда сеть занята передачей информации примерно на 30—40% всего времени). При большей нагрузке повторные столкновения учащаются настолько, что наступает так называемый коллапс или крах сети, представляющий собой резкое падение ее производительности.
Недостаток всех случайных методов состоит еще и в том, что они не гарантируют величину времени доступа к сети, которая зависит не только от выбора задержки между попытками передачи, но и от общей загруженности сети. Поэтому, например, в сетях, выполняющих задачи управления оборудованием (на производстве, в научных лабораториях), где требуется быстрая реакция на внешние события, сети со случайными методами управления используются довольно редко.
При любом случайном методе управления обменом, использующем детектирование коллизии (в частности, при CSMA/CD), возникает вопрос о том, какой должна быть минимальная длительность пакета, чтобы коллизию обнаружили все начавшие передавать абоненты. Ведь сигнал по любой физической среде распространяется не мгновенно, и при больших размерах сети (диаметре сети) задержка распространения может составлять десятки и сотни микросекунд. Кроме того, информацию об одновременно происходящих событиях разные абоненты получают не в одно время. С тем чтобы рассчитать минимальную длительность пакета, следует обратиться к рис. 4.12.
Пусть L – полная длина сети, V – скорость распространения сигнала в используемом кабеле. Допустим, абонент 1 закончил свою передачу, а абоненты 2 и 3 захотели передавать во время передачи абонента 1 и ждали освобождения сети.
После освобождения сети абонент 2 начнет передавать сразу же, так как он расположен рядом с абонентом 1. Абонент 3 после освобождения сети узнает об этом событии и начнет свою передачу через временной интервал прохождения сигнала по всей длине сети, то есть через время L/V. При этом пакет от абонента 3 дойдет до абонента 2 еще через временной интервал L/V после начала передачи абонентом 3 (обратный путь сигнала). К этому моменту передача пакета абонентом 2 не должна закончиться, иначе абонент 2 так и не узнает о столкновении пакетов (о коллизии), в результате чего будет передан неправильный пакет.
Получается, что минимально допустимая длительность пакета в сети должна составлять 2L/V, то есть равняться удвоенному времени распространения сигнала по полной длине сети (или по пути наибольшей длины в сети). Это время называется двойным или круговым временем задержки сигнала в сети или PDV (Path Delay Value). Этот же временной интервал можно рассматривать как универсальную меру одновременности любых событий в сети.
Стандартом на сеть задается как раз величина PDV, определяющая минимальную длину пакета, и из нее уже рассчитывается допустимая длина сети. Дело в том, что скорость распространения сигнала в сети для разных кабелей отличается. Кроме того, надо еще учитывать задержки сигнала в различных сетевых устройствах. Расчетам допустимых конфигураций сети Ethernet посвящена глава 10.
Отдельно следует остановиться на том, как сетевые адаптеры распознают коллизию в кабеле шины, то есть столкновение пакетов. Ведь простое побитное сравнение передаваемой абонентом информации с той, которая реально присутствует в сети, возможно только в случае самого простого кода NRZ, используемого довольно редко. При применении манчестерского кода, который обычно подразумевается в случае метода управления обменом CSMA/CD, требуется принципиально другой подход.
Как уже отмечалось, сигнал в манчестерском коде всегда имеет постоянную составляющую, равную половине размаха сигнала (если один из двух уровней сигнала нулевой). Однако в случае столкновения двух и более пакетов (при коллизии) это правило выполняться не будет. Постоянная составляющая суммарного сигнала в сети будет обязательно больше или меньше половины размаха (рис. 4.13). Ведь пакеты всегда отличаются друг от друга и к тому же сдвинуты друг относительно друга во времени. Именно по выходу уровня постоянной составляющей за установленные пределы и определяет каждый сетевой адаптер наличие коллизии в сети.
Определение факта коллизии в шине при использовании манчестерского кода
Рис. 4.13. Определение факта коллизии в шине при использовании манчестерского кода
Задача обнаружения коллизии существенно упрощается, если используется не истинная шина, а равноценная ей пассивная звезда (рис. 4.14).
Обнаружение коллизии в сети пассивная звезда
Рис. 4.14. Обнаружение коллизии в сети пассивная звезда
При этом каждый абонент соединяется с центральным концентратором, как правило, двумя кабелями, каждый из которых передает информацию в своем направлении. Во время передачи своего пакета абоненту достаточно всего лишь контролировать, не приходит ли ему в данный момент по встречному кабелю (приемному) другой пакет. Если встречный пакет приходит, то детектируется коллизия. Точно так же обнаруживает коллизии и концентратор.
Управление обменом в сети с топологией кольцо
Кольцевая топология имеет свои особенности при выборе метода управления обменом. В этом случае важно то, что любой пакет, посланный по кольцу, последовательно пройдя всех абонентов, через некоторое время возвратится в ту же точку, к тому же абоненту, который его передавал (так как топология замкнутая). Здесь нет одновременного распространения сигнала в две стороны, как в топологии шина. Как уже отмечалось, сети с топологией кольцо бывают однонаправленными и двунаправленными. Наиболее распространены однонаправленные.
В сети с топологией кольцо можно использовать различные централизованные методы управления (как в звезде), а также методы случайного доступа (как в шине), но чаще выбирают все-таки специфические методы управления, в наибольшей степени соответствующие особенностям кольца.
Самые популярные методы управления в кольцевых сетях маркерные (эстафетные), те, которые используют маркер (эстафету) – небольшой управляющий пакет специального вида. Именно эстафетная передача маркера по кольцу позволяет передавать право на захват сети от одного абонента к другому. Маркерные методы относятся к децентрализованным и детерминированным методам управления обменом в сети. В них нет явно выраженного центра, но существует четкая система приоритетов, и потому не бывает конфликтов.
Работа маркерного метода управления в сети с топологией кольцо представлена на рис. 4.15.
Рис. 4.15. Маркерный метод управления обменом (СМ—свободный маркер, ЗМ— занятый маркер, МП— занятый маркер с подтверждением, ПД—пакет данных)
По кольцу непрерывно ходит специальный управляющий пакет минимальной длины, маркер, предоставляющий абонентам право передавать свой пакет. Алгоритм действий абонентов:
1. Абонент 1, желающий передать свой пакет, должен дождаться прихода к нему свободного маркера. Затем он присоединяет к маркеру свой пакет, помечает маркер как занятый и отправляет эту посылку следующему по кольцу абоненту.
2. Все остальные абоненты (2, 3, 4), получив маркер с присоединенным пакетом, проверяют, им ли адресован пакет. Если пакет адресован не им, то они передают полученную посылку (маркер + пакет) дальше по кольцу.
3. Если какой-то абонент (в данном случае это абонент 2) распознает пакет как адресованный ему, то он его принимает, устанавливает в маркере бит подтверждения приема и передает посылку (маркер + пакет) дальше по кольцу.
4. Передававший абонент 1 получает свою посылку, прошедшую по всему кольцу, обратно, помечает маркер как свободный, удаляет из сети свой пакет и посылает свободный маркер дальше по кольцу. Абонент, желающий передавать, ждет этого маркера, и все повторяется снова.
Приоритет при данном методе управления получается географический, то есть право передачи после освобождения сети переходит к следующему по направлению кольца абоненту от последнего передававшего абонента. Но эта система приоритетов работает только при большой интенсивности обмена. При малой интенсивности обмена все абоненты равноправны, и время доступа к сети каждого из них определяется только положением маркера в момент возникновения заявки на передачу.
В чем-то рассматриваемый метод похож на метод опроса (централизованный), хотя явно выделенного центра здесь не существует. Однако некий центр обычно все-таки присутствует. Один из абонентов (или специальное устройство) должен следить, чтобы маркер не потерялся в процессе прохождения по кольцу (например, из-за действия помех или сбоя в работе какого-то абонента, а также из-за подключения и отключения абонентов). В противном случае механизм доступа работать не будет. Следовательно, надежность управления в данном случае снижается (выход центра из строя приводит к полной дезорганизации обмена). Существуют специальные средства для повышения надежности и восстановления центра контроля маркера.
Основное преимущество маркерного метода перед CSMA/CD состоит в гарантированной величине времени доступа. Его максимальная величина, как и при централизованном методе, составит (N-1)• tпк, где N – полное число абонентов в сети, tпк – время прохождения пакета по кольцу. Вообще, маркерный метод управления обменом при большой интенсивности обмена в сети (загруженность более 30—40%) гораздо эффективнее случайных методов. Он позволяет сети работать с большей нагрузкой, которая теоретически может даже приближаться к 100%.
Метод маркерного доступа используется не только в кольце (например, в сети IBM Token Ring или FDDI), но и в шине (в частности, сеть Arcnet-BUS), а также в пассивной звезде (к примеру, сеть Arcnet-STAR). В этих случаях реализуется не физическое, а логическое кольцо, то есть все абоненты последовательно передают друг другу маркер, и эта цепочка передачи маркеров замкнута в кольцо (рис. 4.16). При этом совмещаются достоинства физической топологии шина и маркерного метода управления.
Применение маркерного метода управления в шине
Рис. 4.16. Применение маркерного метода управления в шине
Информация в локальных сетях, как правило, передается отдельными порциями, кусками, называемыми в различных источниках пакетами (packets), кадрами (frames) или блоками. Причем предельная длина этих пакетов строго ограничена (обычно величиной в несколько килобайт). Ограничена длина пакета и снизу (как правило, несколькими десятками байт). Выбор пакетной передачи связан с несколькими важными соображениями.
Назначение пакетов и их структура
Информация в локальных сетях, как правило, передается отдельными порциями, кусками, называемыми в различных источниках пакетами (packets), кадрами (frames) или блоками. Причем предельная длина этих пакетов строго ограничена (обычно величиной в несколько килобайт). Ограничена длина пакета и снизу (как правило, несколькими десятками байт). Выбор пакетной передачи связан с несколькими важными соображениями.
Локальная сеть, как уже отмечалось, должна обеспечивать качественную, прозрачную связь всем абонентам (компьютерам) сети. Важнейшим параметром является так называемое время доступа к сети (access time), которое определяется как временной интервал между моментом готовности абонента к передаче (когда ему есть, что передавать) и моментом начала этой передачи. Это время ожидания абонентом начала своей передачи. Естественно, оно не должно быть слишком большим, иначе величина реальной, интегральной скорости передачи информации между приложениями сильно уменьшится даже при высокоскоростной связи.
Ожидание начала передачи связано с тем, что в сети не может происходить несколько передач одновременно (во всяком случае, при топологиях шина и кольцо). Всегда есть только один передатчик и один приемник (реже – несколько приемников). В противном случае информация от разных передатчиков смешивается и искажается. В связи с этим абоненты передают свою информацию по очереди. И каждому абоненту, прежде чем начать передачу, надо дождаться своей очереди. Вот это время ожидания своей очереди и есть время доступа.
Если бы вся требуемая информация передавалась каким-то абонентом сразу, непрерывно, без разделения на пакеты, то это привело бы к монопольному захвату сети этим абонентом на довольно продолжительное время. Все остальные абоненты вынуждены были бы ждать окончания передачи всей информации, что в ряде случаев могло бы потребовать десятков секунд и даже минут (например, при копировании содержимого целого жесткого диска). С тем чтобы уравнять в правах всех абонентов, а также сделать примерно одинаковыми для всех них величину времени доступа к сети и интегральную скорость передачи информации, как раз и применяются пакеты (кадры) ограниченной длины. Важно также и то, что при передаче больших массивов информации вероятность ошибки из-за помех и сбоев довольно высока. Например, при характерной для локальных сетей величине вероятности одиночной ошибки в 10-8пакет длиной 10 Кбит будет искажен с вероятностью 10-4, а массив длиной 10 Мбит – уже с вероятностью 10-1. К тому же выявить ошибку в массиве из нескольких мегабайт намного сложнее, чем в пакете из нескольких килобайт. А при обнаружении ошибки придется повторить передачу всего большого массива. Но и при повторной передаче большого массива снова высока вероятность ошибки, и процесс этот при слишком большом массиве может повторяться до бесконечности.
С другой стороны, сравнительно большие пакеты имеют преимущества перед очень маленькими пакетами, например, перед побайтовой (8 бит) или пословной (16 бит или 32 бита) передачей информации.
Дело в том, что каждый пакет помимо собственно данных, которые требуется передать, должен содержать некоторое количество служебной информации. Прежде всего, это адресная информация, которая определяет, от кого и кому передается данный пакет (как на почтовом конверте – адреса получателя и отправителя). Если порция передаваемых данных будет очень маленькой (например, несколько байт), то доля служебной информации станет непозволительно высокой, что резко снизит интегральную скорость обмена информацией по сети.
Существует некоторая оптимальная длина пакета (или оптимальный диапазон длин пакетов), при которой средняя скорость обмена информацией по сети будет максимальна. Эта длина не является неизменной величиной, она зависит от уровня помех, метода управления обменом, количества абонентов сети, характера передаваемой информации, и от многих других факторов. Имеется диапазон длин, который близок к оптимуму.
Таким образом, процесс информационного обмена в сети представляет собой чередование пакетов, каждый из которых содержит информацию, передаваемую от абонента к абоненту.
Передача пакетов в сети между двумя абонентами
Рис. 4.1. Передача пакетов в сети между двумя абонентами
В частном случае (рис. 4.1) все эти пакеты могут передаваться одним абонентом (когда другие абоненты не хотят передавать). Но обычно в сети чередуются пакеты, посланные разными абонентами (рис. 4.2).
Передача пакетов в сети между несколькими абонентами
Рис. 4.2. Передача пакетов в сети между несколькими абонентами
Структура и размеры пакета в каждой сети жестко определены стандартом на данную сеть и связаны, прежде всего, с аппаратурными особенностями данной сети, выбранной топологией и типом среды передачи информации. Кроме того, эти параметры зависят от используемого протокола (порядка обмена информацией).
Но существуют некоторые общие принципы формирования структуры пакета, которые учитывают характерные особенности обмена информацией по любым локальным сетям.
Чаще всего пакет содержит в себе следующие основные поля или части (рис. 4.3):
Типичная структура пакета
Рис. 4.3. Типичная структура пакета
* Стартовая комбинация битов или преамбула, которая обеспечивает предварительную настройку аппаратуры адаптера или другого сетевого устройства на прием и обработку пакета. Это поле может полностью отсутствовать или же сводиться к единственному стартовому биту.
* Сетевой адрес (идентификатор) принимающего абонента, то есть индивидуальный или групповой номер, присвоенный каждому принимающему абоненту в сети. Этот адрес позволяет приемнику распознать пакет, адресованный ему лично, группе, в которую он входит, или всем абонентам сети одновременно (при широком вещании).
* Сетевой адрес (идентификатор) передающего абонента, то есть индивидуальный номер, присвоенный каждому передающему абоненту. Этот адрес информирует принимающего абонента, откуда пришел данный пакет. Включение в пакет адреса передатчика необходимо в том случае, когда одному приемнику могут попеременно приходить пакеты от разных передатчиков.
* Служебная информация, которая может указывать на тип пакета, его номер, размер, формат, маршрут его доставки, на то, что с ним надо делать приемнику и т.д.
* Данные (поле данных) – это та информация, ради передачи которой используется пакет. В отличие от всех остальных полей пакета поле данных имеет переменную длину, которая, собственно, и определяет полную длину пакета. Существуют специальные управляющие пакеты, которые не имеют поля данных. Их можно рассматривать как сетевые команды. Пакеты, включающие поле данных, называются информационными пакетами. Управляющие пакеты могут выполнять функцию начала и конца сеанса связи, подтверждения приема информационного пакета, запроса информационного пакета и т.д.
* Контрольная сумма пакета – это числовой код, формируемый передатчиком по определенным правилам и содержащий в свернутом виде информацию обо всем пакете. Приемник, повторяя вычисления, сделанные передатчиком, с принятым пакетом, сравнивает их результат с контрольной суммой и делает вывод о правильности или ошибочности передачи пакета. Если пакет ошибочен, то приемник запрашивает его повторную передачу. Обычно используется циклическая контрольная сумма (CRC). Подробнее об этом рассказано в главе 7.
* Стоповая комбинация служит для информирования аппаратуры принимающего абонента об окончании пакета, обеспечивает выход аппаратуры приемника из состояния приема. Это поле может отсутствовать, если используется самосинхронизирующийся код, позволяющий определять момент окончания передачи пакета.
Вложение кадра в пакет
Рис. 4.4. Вложение кадра в пакет
Нередко в структуре пакета выделяют всего три поля:
* Начальное управляющее поле пакета (или заголовок пакета), то есть поле, включающее в себя стартовую комбинацию, сетевые адреса приемника и передатчика, а также служебную информацию.
* Поле данных пакета.
* Конечное управляющее поле пакета (заключение, трейлер), куда входят контрольная сумма и стоповая комбинация, а также, возможно, служебная информация.
Как уже упоминалось, помимо термина "пакет" (packet) в литературе также нередко встречается термин "кадр" (frame). Иногда под этими терминами имеется в виду одно и то же. Но иногда подразумевается, что кадр и пакет различаются. Причем единства в объяснении этих различий не наблюдается.
В некоторых источниках утверждается, что кадр вложен в пакет. В этом случае все перечисленные поля пакета кроме преамбулы и стоповой комбинации относятся к кадру (рис. 4.4). Например, в описаниях сети Ethernet говорится, что в конце преамбулы передается признак начала кадра.
В других, напротив, поддерживается мнение о том, что пакет вложен в кадр. И тогда под пакетом подразумевается только информация, содержащаяся в кадре, который передается по сети и снабжен служебными полями.
Во избежание путаницы, в данной книге термин "пакет" будет использоваться как более понятный и универсальный.
В процессе сеанса обмена информацией по сети между передающим и принимающим абонентами происходит обмен информационными и управляющими пакетами по установленным правилам, называемым протоколом обмена. Это позволяет обеспечить надежную передачу информации при любой интенсивности обмена по сети.
Пример простейшего протокола показан на рис. 4.5.
Пример обмена пакетами при сеансе связи
Рис. 4.5. Пример обмена пакетами при сеансе связи
Сеанс обмена начинается с запроса передатчиком готовности приемника принять данные. Для этого используется управляющий пакет "Запрос". Если приемник не готов, он отказывается от сеанса специальным управляющим пакетом. В случае, когда приемник готов, он посылает в ответ управляющий пакет "Готовность". Затем начинается собственно передача данных. При этом на каждый полученный информационный пакет приемник отвечает управляющим пакетом "Подтверждение". В случае, когда пакет данных передан с ошибками, в ответ на него приемник запрашивает повторную передачу. Заканчивается сеанс управляющим пакетом "Конец", которым передатчик сообщает о разрыве связи. Существует множество стандартных протоколов, которые используют как передачу с подтверждением (с гарантированной доставкой пакета), так и передачу без подтверждения (без гарантии доставки пакета). Подробнее о протоколах обмена будет рассказано в следующей главе.
При реальном обмене по сети применяются многоуровневые протоколы, каждый из уровней которых предполагает свою структуру пакета (адресацию, управляющую информацию, формат данных и т.д.). Ведь протоколы высоких уровней имеют дело с такими понятиями, как файл-сервер или приложение, запрашивающее данные у другого приложения, и вполне могут не иметь представления ни о типе аппаратуры сети, ни о методе управления обменом. Все пакеты более высоких уровней последовательно вкладываются в передаваемый пакет, точнее, в поле данных передаваемого пакета (рис. 4.6). Этот процесс последовательной упаковки данных для передачи называется также инкапсуляцией пакетов.
Многоуровневая система вложения пакетов
Рис. 4.6. Многоуровневая система вложения пакетов
Каждый следующий вкладываемый пакет может содержать собственную служебную информацию, располагающуюся как до данных (заголовок), так и после них (трейлер), причем ее назначение может быть различным. Безусловно, доля вспомогательной информации в пакетах при этом возрастает с каждым следующим уровнем, что снижает эффективную скорость передачи данных. Для увеличения этой скорости предпочтительнее, чтобы протоколы обмена были проще, и уровней этих протоколов было меньше. Иначе никакая скорость передачи битов не поможет, и быстрая сеть может передавать файл дольше, чем медленная сеть, которая пользуется более простым протоколом.
Обратный процесс последовательной распаковки данных приемником называется декапсуляцией пакетов.
Чаще всего аналоговое кодирование используется при передаче информации по каналу с узкой полосой пропускания, например, по телефонным линиям в глобальных сетях. Кроме того, аналоговое кодирование применяется в радиоканалах, что позволяет обеспечивать связь между многими пользователями одновременно.
Код RZ
Код RZ (Return to Zero – с возвратом к нулю) – этот трехуровневый код получил такое название потому, что после значащего уровня сигнала в первой половине битового интервала следует возврат к некоему "нулевому", среднему уровню (например, к нулевому потенциалу). Переход к нему происходит в середине каждого битового интервала. Логическому нулю, таким образом, соответствует положительный импульс, логической единице – отрицательный (или наоборот) в первой половине битового интервала.
В центре битового интервала всегда есть переход сигнала (положительный или отрицательный), следовательно, из этого кода приемник легко может выделить синхроимпульс (строб). Возможна временная привязка не только к началу пакета, как в случае кода NRZ, но и к каждому отдельному биту, поэтому потери синхронизации не произойдет при любой длине пакета.
Еще одно важное достоинство кода RZ – простая временная привязка приема, как к началу последовательности, так и к ее концу. Приемник просто должен анализировать, есть изменение уровня сигнала в течение битового интервала или нет. Первый битовый интервал без изменения уровня сигнала соответствует окончанию принимаемой последовательности бит (рис. 3.12). Поэтому в коде RZ можно использовать передачу последовательностями переменной длины.
Определение начала и конца приема при коде RZ
Рис. 3.12. Определение начала и конца приема при коде RZ
Недостаток кода RZ состоит в том, что для него требуется вдвое большая полоса пропускания канала при той же скорости передачи по сравнению с NRZ (так как здесь на один битовый интервал приходится два изменения уровня сигнала). Например, для скорости передачи информации 10 Мбит/с требуется пропускная способность линии связи 10 МГц, а не 5 МГц, как при коде NRZ (рис. 3.13).
Скорость передачи и пропускная способность при коде RZ
Рис. 3.13. Скорость передачи и пропускная способность при коде RZ
Другой важный недостаток – наличие трех уровней, что всегда усложняет аппаратуру как передатчика, так и приемника.
Код RZ применяется не только в сетях на основе электрического кабеля, но и в оптоволоконных сетях. Правда, в них не существует положительных и отрицательных уровней сигнала, поэтому используется три следующие уровня: отсутствие света, "средний" свет, "сильный" свет. Это очень удобно: даже когда нет передачи информации, свет все равно присутствует, что позволяет легко определить целостность оптоволоконной линии связи без дополнительных мер (рис. 3.14).
Использование кода RZ в оптоволоконных сетях
Рис. 3.14. Использование кода RZ в оптоволоконных сетях
Манчестерский код
Манчестерский код (или код Манчестер-II) получил наибольшее распространение в локальных сетях. Он также относится к самосинхронизирующимся кодам, но в отличие от RZ имеет не три, а всего два уровня, что способствует его лучшей помехозащищенности и упрощению приемных и передающих узлов. Логическому нулю соответствует положительный переход в центре битового интервала (то есть первая половина битового интервала – низкий уровень, вторая половина – высокий), а логической единице соответствует отрицательный переход в центре битового интервала (или наоборот).
Как и в RZ, обязательное наличие перехода в центре бита позволяет приемнику манчестерского кода легко выделить из пришедшего сигнала синхросигнал и передать информацию сколь угодно большими последовательностями без потерь из-за рассинхронизации. Допустимое расхождение часов приемника и передатчика может достигать 25%.
Подобно коду RZ, при использовании манчестерского кода требуется пропускная способность линии в два раза выше, чем при применении простейшего кода NRZ. Например, для скорости передачи 10 Мбит/с требуется полоса пропускания 10 МГц (рис. 3.15).
Скорость передачи и пропускная способность при манчестерском коде
Рис. 3.15. Скорость передачи и пропускная способность при манчестерском коде
Как и при коде RZ, в данном случае приемник легко может определить не только начало передаваемой последовательности бит, но и ее конец. Если в течение битового интервала нет перехода сигнала, то прием заканчивается. В манчестерском коде можно передавать последовательности бит переменной длины (рис. 3.16). Процесс определения времени передачи называют еще контролем несущей, хотя в явном виде несущей частоты в данном случае не присутствует.
Определение начала и конца приема при манчестерском коде
Рис. 3.16. Определение начала и конца приема при манчестерском коде
Манчестерский код используется как в электрических, так и в оптоволоконных кабелях (в последнем случае один уровень соответствует отсутствию света, а другой – его наличию).
Основное достоинство манчестерского кода – постоянная составляющая в сигнале (половину времени сигнал имеет высокий уровень, другую половину – низкий). Постоянная составляющая равна среднему значению между двумя уровнями сигнала.
Если высокий уровень имеет положительную величину, а низкий – такую же отрицательную, то постоянная составляющая равна нулю. Это дает возможность легко применять для гальванической развязки импульсные трансформаторы. При этом не требуется дополнительного источника питания для линии связи (как, например, в случае использования оптронной гальванической развязки), резко уменьшается влияние низкочастотных помех, которые не проходят через трансформатор, легко решается проблема согласования.
Если же один из уровней сигнала в манчестерском коде нулевой (как, например, в сети Ethernet), то величина постоянной составляющей в течение передачи будет равна примерно половине амплитуды сигнала. Это позволяет легко фиксировать столкновения пакетов в сети (конфликт, коллизию) по отклонению величины постоянной составляющей за установленные пределы.
Частотный спектр сигнала при манчестерском кодировании включает в себя только две частоты: при скорости передачи 10 Мбит/с это 10 МГц (соответствует передаваемой цепочке из одних нулей или из одних единиц) и 5 МГц (соответствует последовательности из чередующихся нулей и единиц: 1010101010...). Поэтому с помощью простейших полосовых фильтров можно легко избавиться от всех других частот (помехи, наводки, шумы).
Бифазный код
Бифазный код часто рассматривают как разновидность манчестерского, так как их характеристики практически полностью совпадают.
Данный код отличается от классического манчестерского кода тем, что он не зависит от перемены мест двух проводов кабеля. Особенно это удобно в случае, когда для связи применяется витая пара, провода которой легко перепутать. Именно этот код используется в одной из самых известных сетей Token-Ring компании IBM.
Принцип данного кода прост: в начале каждого битового интервала сигнал меняет уровень на противоположный предыдущему, а в середине единичных (и только единичных) битовых интервалов уровень изменяется еще раз. Таким образом, в начале битового интервала всегда есть переход, который используется для самосинхронизации. Как и в случае классического манчестерского кода, в частотном спектре при этом присутствует две частоты. При скорости 10 Мбит/с это частоты 10 МГц (при последовательности одних единиц: 11111111...) и 5 МГц (при последовательности одних нулей: 00000000...).
Имеется также еще один вариант бифазного кода (его еще называют дифференциальным манчестерским кодом). В этом коде единице соответствует наличие перехода в начале битового интервала, а нулю – отсутствие перехода в начале битового интервала (или наоборот). При этом в середине битового интервала переход имеется всегда, и именно он служит для побитовой самосинхронизации приемника. Характеристики этого варианта кода также полностью соответствуют характеристикам манчестерского кода.
Здесь же стоит упомянуть о том, что часто совершенно неправомерно считается, что единица измерения скорости передачи бод – это то же самое, что бит в секунду, а скорость передачи в бодах равняется скорости передачи в битах в секунду. Это верно только в случае кода NRZ. Скорость в бодах характеризует не количество передаваемых бит в секунду, а число изменений уровня сигнала в секунду. И при RZ или манчестерском кодах требуемая скорость в бодах оказывается вдвое выше, чем при NRZ. В бодах измеряется скорость передачи сигнала, а в битах в секунду – скорость передачи информации. Поэтому, чтобы избежать неоднозначного понимания, скорость передачи по сети лучше указывать в битах в секунду (бит/с, Кбит/с, Мбит/с, Гбит/с).
Другие коды
Все разрабатываемые в последнее время коды призваны найти компромисс между требуемой при заданной скорости передачи полосой пропускания кабеля и возможностью самосинхронизации. Разработчики стремятся сохранить самосинхронизацию, но не ценой двукратного увеличения полосы пропускания, как в рассмотренных RZ, манчестерском и бифазном кодах.
Чаще всего для этого в поток передаваемых битов добавляют биты синхронизации. Например, один бит синхронизации на 4, 5 или 6 информационных битов или два бита синхронизации на 8 информационных битов. В действительности все обстоит несколько сложнее: кодирование не сводится к простой вставке в передаваемые данные дополнительных битов. Группы информационных битов преобразуются в передаваемые по сети группы с количеством битов на один или два больше. Приемник осуществляет обратное преобразование, восстанавливает исходные информационные биты. Довольно просто осуществляется в этом случае и обнаружение несущей частоты (детектирование передачи).
Так, например, в сети FDDI (скорость передачи 100 Мбит/с) применяется код 4В/5В, который 4 информационных бита преобразует в 5 передаваемых битов. При этом синхронизация приемника осуществляется один раз на 4 бита, а не в каждом бите, как в случае манчестерского кода. Но зато требуемая полоса пропускания увеличивается по сравнению с кодом NRZ не в два раза, а только в 1,25 раза (то есть составляет не 100 МГц, а всего лишь 62,5 МГц). По тому же принципу строятся и другие коды, в частности, 5В/6В, используемый в стандартной сети 100VG-AnyLAN, или 8В/10В, применяемый в сети Gigabit Ethernet.
В сегменте 100BASE-T4 сети Fast Ethernet использован несколько иной подход. Там применяется код 8В/6Т, предусматривающий параллельную передачу трех трехуровневых сигналов по трем витым парам. Это позволяет достичь скорости передачи 100 Мбит/с на дешевых кабелях с витыми парами категории 3, имеющих полосу пропускания всего лишь16 МГц (см. табл. 2.1). Правда, это требует большего расхода кабеля и увеличения количества приемников и передатчиков. К тому же принципиально, чтобы все провода были одной длины и задержки сигнала в них не слишком различались.
Иногда уже закодированная информация подвергается дополнительному кодированию, что позволяет упростить синхронизацию на приемном конце. Наибольшее распространение для этого получили 2-уровневый код NRZI, применяемый в оптоволоконных сетях (FDDI и 100BASE-FX), а также 3-уровневый код MLT-3, используемый в сетях на витых парах (TPDDI и 100BASE-TХ). Оба эти кода (рис. 3.17) не являются самосинхронизирующимися.
Коды NRZI и MLT-3
Рис. 3.17. Коды NRZI и MLT-3
Код NRZI (без возврата к нулю с инверсией единиц – Non-Return to Zero, Invert to one) предполагает, что уровень сигнала меняется на противоположный в начале единичного битового интервала и не меняется при передаче нулевого битового интервала. При последовательности единиц на границах битовых интервалов имеются переходы, при последовательности нулей – переходов нет. В этом смысле код NRZI лучше синхронизируется, чем NRZ (там нет переходов ни при последовательности нулей, ни при последовательности единиц).
Код MLT-3 (Multi-Level Transition-3) предполагает, что при передаче нулевого битового интервала уровень сигнала не меняется, а при передаче единицы – меняется на следующий уровень по такой цепочке: +U, 0, –U, 0, +U, 0, –U и т.д. Таким образом, максимальная частота смены уровней получается вчетверо меньше скорости передачи в битах (при последовательности сплошных единиц). Требуемая полоса пропускания оказывается меньше, чем при коде NRZ.
Все упомянутые в данном разделе коды предусматривают непосредственную передачу в сеть цифровых двух- или трехуровневых прямоугольных импульсов.
Однако иногда в сетях используется и другой путь – модуляция информационными импульсами высокочастотного аналогового сигнала (синусоидального). Такое аналоговое кодирование позволяет при переходе на широкополосную передачу существенно увеличить пропускную способность канала связи (в этом случае по сети можно передавать несколько бит одновременно). К тому же, как уже отмечалось, при прохождении по каналу связи аналогового сигнала (синусоидального) не искажается форма сигнала, а только уменьшается его амплитуда, а в случае цифрового сигнала форма сигнала искажается (см. рис. 3.2).
К самым простым видам аналогового кодирования относятся следующие (рис. 3.18):
* Амплитудная модуляция (АМ, AM – Amplitude Modulation), при которой логической единице соответствует наличие сигнала (или сигнал большей амплитуды), а логическому нулю – отсутствие сигнала (или сигнал меньшей амплитуды). Частота сигнала при этом остается постоянной. Недостаток амплитудной модуляции состоит в том, что АМ-сигнал сильно подвержен действию помех и шумов, а также предъявляет повышенные требования к затуханию сигнала в канале связи. Достоинства – простота аппаратурной реализации и узкий частотный спектр.
Аналоговое кодирование цифровой информации
Рис. 3.18. Аналоговое кодирование цифровой информации
* Частотная модуляция (ЧМ, FM – Frequency Modulation), при которой логической единице соответствует сигнал более высокой частоты, а логическому нулю – сигнал более низкой частоты (или наоборот). Амплитуда сигнала при частотной модуляции остается постоянной, что является большим преимуществом по сравнению с амплитудной модуляцией.
* Фазовая модуляция (ФМ, PM – Phase Modulation), при которой смене логического нуля на логическую единицу и наоборот соответствует резкое изменение фазы синусоидального сигнала одной частоты и амплитуды. Важно, что амплитуда модулированного сигнала остается постоянной, как и в случае частотной модуляции.
Применяются и значительно более сложные методы модуляции, являющиеся комбинацией перечисленных простейших методов. Чаще всего аналоговое кодирование используется при передаче информации по каналу с узкой полосой пропускания, например, по телефонным линиям в глобальных сетях. Кроме того, аналоговое кодирование применяется в радиоканалах, что позволяет обеспечивать связь между многими пользователями одновременно. В локальных кабельных сетях аналоговое кодирование практически не используется из-за высокой сложности и стоимости как кодирующего, так и декодирующего оборудования.
Откроем замечательную векторную программу Adobe Illustrator и попробуем нарисовать кусочек сыра (если вы не знаете, что такое векторный и подобные вещи, то читайте статью «Первые шаги - компьютерная графика и графические редакторы»).
Изучаем векторную графику (Adobe Illustrator).
Откроем замечательную векторную программу Adobe Illustrator и попробуем нарисовать кусочек сыра (если вы не знаете, что такое векторный и подобные вещи, то читайте статью «Первые шаги - компьютерная графика и графические редакторы»).
Для начала нужно создать новый документ (лист бумаги, на котором будем рисовать). В меню выбираем File - New...
Выбираем нужные размеры документа, и наживаем OK, чтобы его создать (в данном случае, взяты значения, те, что предложил Иллюстратор по умолчанию).
Так как рисуем сыр с нуля и еще не умеем, то воспользуемся сыром образцом (будем срисовывать).
Чтобы поместить не векторное изображение на лист, выбираем в меню: File - Place... - выбираем рисунок, который надо разместить на листе.
Прежде чем начать работать с сыром, его надо увеличить. Чтобы сделать саму картинку с сыром больше, надо кликнуть по ней левой кнопкой мыши - таким образом, выделится объект и вокруг него появится рамочка. Потянем за уголок - и таким образом можно изменить размер картинки. Чтобы при этом картинка не деформировалась и сохраняла пропорции, то придерживаем, когда тянем за уголок, клавишу Shift на клавиатуре.
Чтобы изменить видимый размер картинки (приблизить - отдалить) - выберем инструмент лупа (zoom tool) на основной панели инструментов. Этот инструмент, наводим на картинку, кликаем левой кнопкой мыши - изображение приблизится. Если наоборот, отдалить, то кликаем мышью по изображению, придерживая кнопку Alt на клавиатуре. Чтобы снова работать с изображением (т.е. выйти из режима лупы), надо выбрать другой инструмент на панели инструментов (например, следующий инструмент, с которым вы будете работать).
Итак, видимый размер куска сыра увеличен, чтобы было удобнее его обрисовывать, теперь фиксируем картинку с сыром на листе, чтобы, когда с ней начнем работать, она никуда не сдвинулась нечаянно. Для этого выбираем на панели инструментов черную стрелку (selecтion tool), после чего кликаем по рисунку, чтобы его выделить (всегда, объект, с которым работаем, должен быть выделен), затем в меню выбираем Object - Lock - Selecтion.
На панели инструментов выбираем инструмент перо (pen tool), с помощью него обрисовываем сыр. Но прежде чем, обрисовать сыр, надо убрать заливку объекта. Квадраты - белый и черный - внизу панели инструментов, указывают, какой цвет будет у объекта, который рисуем - он будет белым, и вокруг него будет черная граница.
Чтобы изменить цвет границы или цвет объекта - кликаем два раза по нужному квадрату (если нужно изменить границу - то по черному, в данном случае, если цвет объекта - по белому), и появится окошко, где можно выбрать другой, нужный цвет. Но в этом случае, другой цвет не нужен, надо, чтобы объект не был закрашен, и было видно только границу (контур объекта) - так будет удобнее срисовывать. Поэтому одним кликом мыши выбираем белый квадрат, и под ним выбираем иконку с квадратом, перечеркнутым красной полосой - таким образом, говорим иллюстратору - отмени заливку объекта белым цветом, и он это сделает.
Теперь начнем обрисовывать сыр, сначала светлую верхнюю плоскость, а затем нижнюю. Кликнем, допустим, в одном из уголков сыра, затем, повторяя контур сыра, кликаем дальше. Чтобы все линии (отрезки, которые появятся при этом), были прямыми, то когда надо кликнуть мышью, чтобы создать очередную точку, не отпуская левую клавишу мыши, тогда удерживая ее и двигая мышью, можно выгнуть отрезок, как угодно, и таким образом более точно обвести сыр.
Если был сделан отрезок кривым (выгнутым), то прежде чем продолжать обрисовывать объект, надо кликнуть левой кнопкой мыши по последней точке, которую поставили, и только затем создавать новую точку и отрезок. Если этого не сделаете, то следующий отрезок выгнется подобно предыдущему.
Если не верно поставлена точка, если отрезок как-то не так выгнут, то чтобы отменить действие, нажимаем на клавиатуре Ctrl+Z. Если отменили предыдущее действие ошибочно, то нажмите Ctrl+Shift+Z, чтобы вернуть все обратно.
Чтобы завершить обрисовывать верхнюю часть сыра надо обязательно закончить в той точке, с которой начали, чтобы получить цельный объект (т.е. замкнуть наш контур).
Аналогично первому создаем второй контур (объект).
Чтобы нагляднее было видно, что на картинке два контура: второй, недорисованный контур, немного сдвинут в сторону. При этом создание объекта не было прервано. Что делать, если надо довести контур объекта, после того как прервались? Чтобы продолжить работу, надо ткнуть кнопкой мышки в точку объекта, на которой прервались и можно дорисовывать объект дальше (естественно, при этом на панели инструментов должно быть выбрано перо, если надо дорисовать объект; если же надо подвигать объект, то переключаемся на selecтion tool - черная стрелка, только не забыть переключаться на нужные инструменты, прежде чем выполнять какие-то действия над объектом).
Когда нарисованы нужные объекты, следует их закрасить. Как это делается, объяснялось ранее: выделяем объект, и внизу панели через квадраты оперируем цветом. Есть и другие пути: можно вызвать цветовую палитру, чтобы она всегда на экране: Window - Color (опять же выделяем объект, прежде, чем дать ему цвет). Также можно, выделив объект, выбрать инструмент пипетка (eyedroррer tool) на панели инструментов, и ткнуть пипеткой по другому объекту на листе (например, по картинке с сыром, чтобы дать новому объекту такой же цвет, как цвет куска сыра, с которого срисовываем).
На данном примере три куска сыра: один - с какого срисовываем, второй - кусок сыра, которому дали такие же цвета, как сыру на картинке, но т.к. цвета не сырные, заплесневелые, то были подобранны другие цвета, которые можно видеть на третьем куске сыра. Если еще трудно сделать последнее самим, то сохраните картинку с примером на компьютере, поместите ее на лист бумаги в иллюстраторе и при помощи пипетки, дайте вашему куску сыра такие же яркие и приятные цвета, как у третьего куска сыра на картинке с примерами.
Как перемещать и копировать нарисованные объекты? Перемещать объекты надо следующим образом: выделить объект, предварительно выбрав инструмент selecтion tool (черная стрелка) на панели инструментов, а затем при помощи мышки перетащить выбранный объект. Если надо переместить сразу несколько объектов: опять же выбираем selecтion tool, и далее либо удерживая левую кнопку мыши выделяем все объекты, либо кликаем на нужные нам объекты поочередно, удерживая клавишу Shift на клавиатуре. После того как были выделены все нужные объекты, их можно перемещать, куда угодно. Также, выделив объекты, можно скопировать их Edit - Copy. Чтобы вставить скопированные объекты на лист - Edit - Paste. Чтобы удалить, выделенные объекты - Edit - Clear.
После придания куску, который рисуем, нужные цвета, рисуем на нем сырные дырки, чтобы придать ему еще большую схожесть с сыром. Дырки не будем срисовывать с фотографии куска сыра, а нарисуем сами. Дырка - это круг. Круги рисуют при помощи инструмента elliрse tool. Чтобы найти этот инструмент на панели инструментов надо кликнуть мышкой по инструменту квадрат (rectangle tool), удерживая мышку, выпадет меню, в котором надо выбрать elliрse tool. Далее кликаем на нашем листе в любом месте и рисуем круг.
Нарисовав круг, даем ему цвет более насыщенный и темный, чем боковая сторона сыра (т.к. дырка для этой стороны, а дырка она визуально более темная по цвету, чем сама сторона). Если переместить, нарисованный круг, на кусок сыра, то станет понятно, что он еще не смотрится дыркой, не хватает "глубины", так что надо приблизить круг (дырку) ближе к реальности, добавив ей бликов и теней.
Итак, скопируем круг, и вставим скопированное на лист (как это делается, рассказывалось ранее). Затем совместим круги так, как показано на рисунке (в итоге должно быть три круга - один исходный, и два которые, скопировав исходный круг, вставили на лист, а затем совместили между собой новые круги, как показано на рисунке):
Теперь порежем эти круги при помощи Pathfinder. Вызываем его через меню: Window - Pathfinder. Далее оба круга выделяем, и нажимаем в окошке Pathfinder инструмент Divide. Если сейчас попытаться подвигать круги, то обнаружите, что они слиплись в один объект. На самом деле, Divider порезал наши круги на много маленьких объектов, но для удобства, он их потом сгруппировал (вдруг захочется их передвинуть сразу куда-нибудь). Поэтому надо рассгруппировать все объекты. Выделяем нашу группу объектов, выбираем в меню - Object - Ungroup.
Если теперь попробовать мышкой подвигать круги, то видим, что их все-таки разрезали, и получили в итоге три очень интересных объекта: два полумесяца и объект похожий на дыню. Круги и резали, т.к. нужны были полумесяцы. Скопируем один из полумесяцев, вставим на лист, дадим ему цвет чуть бледнее, чем цвет круга, и переместим на круг, как показано на нашем рисунке (см. чуть выше).
Затем еще раз копируем полумесяц и вставляем его на лист, делаем его еще светлее, и переносим на наш круг, как показано на рисунке:
Теперь нужен другой полумесяц, зеркальный тем, что копировали до этого. Берем полумесяц, копируем, даем ему самый темный цвет по сравнению с другими объектами, перемещаем на круг так, как показано на рисунке:
Вот и все, сырная дырка готова, теперь надо переместим ее на сыр. Для этого надо сгруппировать все объекты, имеющие отношение к сырной дырке, чтобы потом было легче их копировать и перемещать при необходимости. Чтобы сгруппировать объекты, их нужно выделить, а затем группируем их, выбрав в меню Object - Group (если надо будет снова разбить объекты, отклеить друг от друга, то выделяем сгруппированные объекты, и при помощи уже знакомого Object - Ungroup).
Итак, переместили дырку на сыр, теперь скопируем ее, и вставим еще несколько новых дырок на боковую сторону сыра. Сделаем их размеры разными (как, уменьшать-увеличивать размер объекта говорили в начале статьи). В итоге, должны получить, вот такой сыр:
Чтобы сыр был похож на настоящий, добавим еще одну полудырку, а так же теней и рефлексов на края.
Для этого берем готовую дырку, копируем, вставляем на лист (отдельно от сыра), и затем при помощи Pathfinder и Divider ее ополовиниваем. Также копируем два полумесяца, которые потом, вставим на край сыра. Получаются две следующие картинки:
Теперь и половинку дырки, и два полумесяца немного развернем при помощи инструмента rotate tool. Края сыра идут немного под наклоном, и чтобы совместить дырки с краями куска сыра, их надо привести в соответствие. Теперь наложим их на кусок сыра, если надо еще чуть-чуть поразворачиваем, и в итоге должны получить следующее:
Итак, кусок сыра почти нарисовали, теперь надо нарисовать дырки для верхней плоскости (копируем уже имеющиеся дырки, и немного изменяем им цвет на посветлее, затем немного их трансформируем до овалов, и разворачиваем при помощи rotate tool):
Теперь еще для красоты можно нарисовать при помощи пера парочку рефлексов и теней, и сыр готов:
Можете идти ловить мышей. Хотя... умея рисовать картинки в Иллюстраторе, вам будет не до мышей.
Событие - это какое-либо действие, осуществляемое пользователем либо браузером. Например, когда мы щелкаем (кликаем) на ссылке - осуществляется событие, его перехватывает специальный обработчик и перенаправляет нас на нужную страницу; при наведении курсора (указателя мыши) на ссылку в строке состояния (обычно находится в нижней части окна браузера) отображается адрес, так как обработчик "наведения курсора на объект (в данном случае на ссылку)" помещает туда этот адрес и так далее...
а). 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 )
При разработке больших приложений, оперирующих большими объемами информации на первое место при отладке встает проблема обнаружения неправильного распределения памяти. Суть проблемы состоит в том, что если мы выделили участок памяти, а затем освободили не весь выделенный объем, то образуются блоки памяти, которые помечены как занятые, но на самом деле они не используются. При длительной работе программы такие блоки могут накапливаться, приводя к значительному расходу памяти.
Для обнаружения подобных ошибок создано специализированное программное обеспечение (типа BoundsChecker от Numega), однако чаще бывает удобнее встроить механизм обнаружения утечки в свои проекты. Поэтому метод должен быть простым, и в то же время как можно более универсальным. Кроме того, не хотелось бы переписывать годами накопленные мегабайты кода, написанного и отлаженного задолго до того, как вам пришло в голову оградить себя от ошибок. Так что к списку требований добавляется стандартизация, т.е. нужно каким-то образом встроить защиту от ошибок в стандартный код.
Предлагаемое решение основывается на перегрузке стандартных операторов распределения памяти new и delete. Причем перегружать мы будем глобальные операторы new|delete, т.к. переписать эти операторы для каждого разработанного ранее класса было бы очень трудоемким процессом. Т.о. после перегрузки нам нужно будет только отследить распределение памяти и, соответственно, освобождение ее в момент завершения программы. Все несоответствия - ошибка.
Реализация
Проект написан на Visual C++, но переписать его на любой другой диалект С++ не будет слишком сложной задачей. Во-первых, нужно переопределить стандартные операторы new и delete так, чтобы это работало во всех проектах. Поэтому в stdafx.h добавляем следующий фрагмент:
Как видите, переопределение операторов происходит в блоке #ifdef/#endif. Это ограждает наш код от влияния на релиз компилируемой программы. Вы, наверное, заметили, что теперь оператор new имеет три параметра вместо одного. Два дополнительных параметра содержат имя файла и номер строки, в которой выделяется память. Это удобно для обнаружения конкретного места, где происходит ошибка. Однако код наших проектов по-прежнему ссылается на оператор new, принимающий один параметр. Для исправления этого несоответствия нужно добавиить следующий фрагмент
Теперь все наши операторы new будут вызываться с тремя параметрами, причем недостающие параметры подставит препроцессор. Конечно, пустые переопределенные функции ни в чем нам не помогут, так что давайте добавим в них какой-нибудь код:
Для полноты картины нужно переопределить операторы new[] и delete[], однако никаких существенных отличий здесь нет - творите!
Последний штрих - пишем функции AddTrack() и RemoveTrack(). Для создания списка используемых блоков памяти будем использовать стандартные средства STL:
Перед самым завершением программы наш список allocList содержит ссылки на блоки памяти, котороые не были освобождены. Все, что нужно сделать - вывести эту информацию куда-нибудь. В нашем проекте мы выведем список неосвобожденных участков памяти в окно вывода отладочных сообщений Visual C++:
Надеюсь, этот проект сделает ваши баг-листы короче, а программы устойчивее. Удачи!
В этом разделе вы создадите два новых приложения OLE. Первое - простая программа-сервер OLE, второе - пример простого контейнера OLE. Эти программы предназначены для демонстрации минимальных затрат программирования, необходимых для создания приложений OLE 2.
В любом случае, для создания оболочки программы следует воспользоваться приложением AppExpert. Сначала необходимо сгенерировать основу приложения в AppExpert, затем модифицировать созданные файлы для создания законченного рабочего примера.
При написании своих версий этих программ необходимо иметь в виду несколько моментов. Во-первых, в этой главе приводятся листинги только исходных, немодифицированных файлов.
Во-вторых, CLSID этих программ будет отличаться от CLSID программ, которые вы сгенерируете с помощью AppExpert. Это нормально и даже необходимо, поскольку с помощью CLSID одни серверные приложения в Windows отличаются от других.
В-третьих, эти примеры содержат минимум необходимых средств для того, чтобы начать программировать с OLE. Вы можете использовать эти примеры в качестве начального кода для создания своего действительно полезного сервера или контейнера. В этой главе просто не хватает места для описания реализации функциональных сервера и контейнера - в этом случае вам понадобился бы грузоподъемник, чтобы положить эту книгу на стол.
Создание сервера OLE
Первое приложение OLE в этой главе - сервер. В этом примере вы построите полный сервер - сервер, который может использоваться и как автономное приложение, и как сервер. Создавая автономный сервер (т.е. в виде исполняемой программы .ЕХЕ, а не в виде динамически подключаемой библиотеки DLL), вы упрощаете процесс регистрации сервера в Windows.
Начальный процесс разработки сервера прост. Сначала из интегрированной среды Borland C++ версии 4.5 запустите AppExpert. Задайте каталог и имя вашего проекта. Я поместил свой проект в каталог \BC45\SOURCE\OLESVR. Проект я назвал OLESVR (я всегда называю проекты и каталоги проектов одним и тем же именем, это облегчает запоминание). Ниже приводится последовательность действий, в результате которых был создан проект OLESVR.
Запустите AppExpert. В первом диалоговом окне следует задать имя и каталог проекта. Как уже отмечалось, я использовал OLESVR для задания обоих.
После выбора ОК в диалоговом окне имени и каталога проекта следующий раздел АррЕхреrt - диалоговое окно Application General Options (основные опции приложения). Это диалоговое окно позволяет задать конфигурацию приложения, генерируемого AppExpert. Вам придется модифицировать несколько опций для проекта OLESVR.
Первая опция, которую необходимо изменить, находится в блоке Application: Summary. Замените параметр по умолчанию Multiple document interface на Single document interface. Это изменение согласуется с призывом Microsoft делать ставку на однодокументные приложения для Windows. На рис. 21.1 демонстрируется модифицированный блок Application: Summary.
Второе изменение, которое необходимо внести, - указать AppExpert, что ваша программа будет сервером OLE. Это изменение вносится в пункт Application: OLE 2 Options, имеющий ряд опций OLE 2, которые можно задавать. Поскольку вы создаете сервер OLE, вы будете оперировать только элементами блока группы OLE 2 Server: (поищите его в правой верхней части диалога). Выберите кнопку ячейки пометки Server EXE. На рис. 21.2 демонстрируются изменения, проведенные в пункте Application:OLE 2 Options.
При желании вы можете заполнить элементы пункта Application: Admin Options блока диалога AppExpert. С его помощью вы можете задать в приложении заметку об авторском праве, имя и информацию о версии. Все элементы в Application: Admin Options необязательны, и вы можете их не задавать.
Подпункты пункта Main Window не нуждаются в модификациях, их следует оставить заданными значениями по умолчанию. Для данного приложения нет необходимости менять что-либо в этих подпунктах. Пункт MDI Child/View неприменим для этого проекта, поэтому нет нужды в нем что-нибудь менять.
После задания всех необходимых модификаций следует выбрать кнопку Generate в нижней части блока диалога AppExpert Application General Options. AppExpert запросит у вас подтверждение, действительно ли вы собираетесь создать проект; после принятия подтверждения AppExpert сгенерирует приложение. На рис. 21.3 приводится конечный проект, загруженный в интегрированную среду Borland C++ версии 4.5.
Теперь, когда программа сгенерирована, в нее следует добавить код, задающий функциональность сервера OLE. Необходимо включить код, рисующий изображение, а также провести другие незначительные изменения.
К счастью, помимо Borland C++ версии 4.5 можно воспользоваться программой ClassExpert, что облегчит внесение большей части изменений. Предположим, вы хотите сперва заняться вопросами отображения. Как и в любой созданной с помощью AppExpert программе, основная часть рисования выполняется классом отображения, производным от класса OWL TOleView. Файл, в котором содержится реализация отображения, имеет имя LSVROLVW.CPP. В листинге 21.1 приводится первоначальный файл OSROLVW.CPP.
Листинг (файл реализации класса отображения OLESVR, OSVROLVW.CPP)
Такие типы данных, как int, float, char и long, являются неотъемлемой частью C/C++ и вам не нужно писать никакого кода, чтобы сообщить компилятору о том, что означают эти слова. C/C++ позволяет вам также объ-являть свои собственные, специальные типы данных. В следующем разделе вы узнаете, как объявлять структуры, которые можно отнести к специальным типам данных.
Как вы уже знаете, переменная в C/C++ объявляется следующим образом:
В приведенном операторе iMyVariable объявлена как целая переменная. А вот объявление переменной типа char:
Напишите следующий исходный код:
В коде, который вы написали, имеются два оператора #include:
Файл iostream.h включен в код, поскольку в main(void) используется cout. Файл string.h включается потому, что в main(void) используется функция strcpy() (объявленная в файле string.h). Затем вы объявляете структуру:
Обратите внимание на синтаксис объявления структуры. Оно начинается с ключевого слова struct, за которым следует имя типа-структуры. В этой программе типу структуры присвоено имя MYSTRUCTURE. Затем следует собственно определение структуры, заключенное в фигурные скобки. Не забудьте поставить точку с запятой после закрывающей фигурной скобки. Теперь посмотрите на код внутри фигурных скобок:
Это означает, что MYSTRUCTURE состоит из строки с именем sName и целого с именем iAge, sName и iAge называются элементами данных структуры; Вы объявили их "Внутри" cтруктуры MYSTRUCTURE. Код в main(void) объявляет переменную с именем MyStructure типа MYSTRUCTURE:
Вспомните, что в объявляли переменную iNum1 следующим образом:
Когда вы объявляете MyStructure , которая будет структурой типа MYSTRUCTURE, рассматривайте переменную MyStructure аналогично переменной iNum1. MyStructure - это имя переменной, а ее типом является MYSTRUCTURE точно так же, как типом переменной iNum1 является int. (Обратите внимание, что по традиции имя структуры составлено из символов нижнего регистра или в нем смешаны символы нижнего и верхнего регистров, как, например, в имени MyStructure, но в имени типа структуры используются только символы верхнего регистра, как, например, в MYSTRUCTURE.)
Следующий оператор в main(void) копирует строку 'Andy' в элемент данных MyStructure.sName:
В этом операторе обращение к элементу данных sName записано как MyStructure.sName Следующий оператор присваивает значение 13 элементу данных iAge cтруктуры MyStructure: MyStructure.iAge - 13; Затем выполняется ряд операторов вывода cout:
Сложив все вместе, мы видим, что программа MyStruct выводит сообщение My name is Andy and I am 13 years old. (Меня зовут Andy и мне 13 лет)
В состав библиотеки MFC входит ряд классов, представляющих стандартные диалоговые панели. Эти классы позволяют легко реализовать такие часто используемые операции, как открытие и сохранение файла, выбор цвета, выбор шрифта и т.д. Все эти классы наследуются от CCommonDialog, который в свою очередь является производным по отношению к базовому классу CDialog.
Приведем классы стандартных диалоговых панелей и их назначение:
CColorDialog - Панель для выбора цвета
CFileDialog - Панель выбора файлов для открытия и сохранения на диске
CFindReplaceDialog - Панель для выполнения операции поиска и замены
CFontDialog - Панель для выбора шрифта
CPrintDialog - Панель для вывода документа на печать
CPageSetupDialog - Панель выбора формата документа
COleDialog - Панель для управления технологией OLE
Классы, управляющие стандартными диалоговыми панелями, определены в файле afxdlgs.h. Поэтому при использовании этих классов в приложении необходимо включить этот файл в исходный текст при помощи директивы #include.
Панель выбора цвета (класс CColorDialog)
Чтобы отобразить на экране стандартную диалоговую панель выбора цвета, надо создать объект класса CColorDialog, а затем вызвать метод DoModal. При создании объекта класса СColorDialog используется следующий конструктор:
Все параметры конструктора необязательны, однако в некоторых случаях использование этих параметров может помочь.
Первый параметр clrInit позволяет указать цвет, выбранный по умолчанию сразу после открытия диалоговой панели. Если параметр не будет указан, в качестве цвета, выбранного по умолчанию, будет использоваться черный цвет.
Параметр dwFlags содержит набор флагов, управляющих диалоговой панелью выбора цвета. При помощи него блокировать или разрешать работу некоторых элементов управления диалоговой панели выбора цвета. Если при создании объекта класса CColorDialog не указать параметр dwFlags, тем не менее можно выполнить настройку диалоговой панели, обратившись непосредственно к элементу m_cc данного класса. Параметр dwFlags, указанный в конструкторе, используется для инициализации m_cc. Изменения в элемент m_cc должны быть внесены до того, как панель будет отображаться на экране.
Последний параметр pParentWnd можно использовать, чтобы указать родительское окно диалоговой панели.
Методы класса CСolorDialog
Чтобы вывести диалоговую панель выбора цвета на экран, необходимо использовать метод DoModal. После отображения панели на экране пользователь может выбрать из нее цвет и нажать кнопки OK или Cancel для подтверждения выбора цвета или отказа от него. Когда диалоговая панель закрывается, метод DoModal возвращается значения IDOK и IDCANCEL, в зависимости от того, какую кнопку нажал пользователь:
На экране появится стандартная диалоговая панель выбора цвета Color. В верхней половине диалоговой панели расположены 48 прямоугольников, имеющих различные цвета. Они представляют так называемые основные цвета (Basic colors). Можно выбрать один из этих цветов и нажать кнопку OK. После того, как диалоговая панель закрыта (метод DoModal завершил свою работу), можно воспользоваться методами класса CColorDialog, чтобы узнать цвета, выбранные пользователем.
Для определения цвета, выбранного пользователем, можно обратиться к методу GetColor класса CColorDialog. Данный метод возвращает значение COLORREF, соответствующее выбранному цвету.
Если пользователю недостаточно основных цветов, представленных в диалоговой панели Color, он может выбрать до 16 дополнительных цветов. Для этого он должен нажать кнопку DefineCustom Colors. Диалоговая панель изменит свой внешний вид - появятся дополнительные органы управления, позволяющие выбрать любой из 16 777 216 цветов. Когда цвет выбран, нужно нажать кнопку Add Custom Colors. Выбранный цвет будет добавлен к дополнительным цветам (Custom colors) - один из свободных прямоугольников окрасится соответствующим цветом.
При помощи метода GetSavedCustomColors класса CColorDialog можно определить дополнительные цвета, выбранные пользователем в диалоговой панели Color. Этот метод возвращает указатель на массив из 16 элементов типа COLORREF. Каждый элемент массива описывает один дополнительный цвет.
Когда диалоговая панель Color отображается приложением первый раз, все прямоугольники, отображающие дополнительные цвета, имеют белый цвет. Дополнительные цвета, выбранные пользователем, сохраняются во время работы приложения. После перезапуска приложения дополнительные цвета сбрасываются.
Панель выбора файлов (класс CFileDialog)
Среди стандартных диалоговых панелей, для которых в библиотеке MFC создан специальный класс, есть панели для работы с файловой системой - Open и Save As. Диалоговая панель Open позволяет выбрать один или несколько файлов и открыть их для дальнейшего использования. Диалоговая панель Save As позволяет выбрать имя файла для записи в него документа.
Для управления диалоговыми панелями Open и Save As предназначен один класс CFileDialog. Рассмотрим конструктор класса CFileDialog более подробно:
Объекты класса CFileDialog представляют диалоговые панели Open или Save As в зависимости от параметра bOpenFileDialog. Если параметр bOpenFileDialog содержит значение TRUE, то создается объект, управляющий диалоговой панелью Open, а если FALSE - диалоговой панелью Save As.
Параметр bOpenFileDialog является единственным обязательным параметром, который необходимо указать. Остальные параметры конструктора класса CFileDialog задают различные режимы работы панели и могут не указываться.
Чтобы создать объект класса CFileDialog , представляющий диалоговую панель для открытия файлов (mFileOpen), и объект, представляющий диалоговую панель для сохранения файлов (mFileSaveAs), можно воспользоваться следующими вызовами конструктора класса:
Во многих случаях имена файлов, которые нужно открыть или закрыть, имеют определенное расширение. Параметр lpszDefExt позволяет задать расширение файлов, используемое по умолчанию. То есть, если пользователь при определении имени файла не укажет расширение, имени файла автоматически присваивается расширение, принятое по умолчанию. Если при определении свойств диалоговой панели программист присвоит параметру lpszDefExt значение NULL, то расширение файлов должно задаваться пользователем явно.
В некоторых случаях требуется, чтобы диалоговые панели отображались с уже выбранным именем файла. Чтобы указать имя файла, используемое по умолчанию, применяется параметр lpszFileName. Если параметр lpszFileName имеет значение NULL, данная возможность не реализуется.
С помощью флага dwFlags можно изменить внешний вид и некоторые другие характеристики стандартных диалоговых панелей класса CFileDialog. В него можно записать комбинацию флагов, управляющих различными характеристиками этих панелей. Например, флаг OFN_HIDEREADONLY означает, что из диалоговой панели удаляется переключатель "Read Only", а флаг OFN_OVERWRITEPROMPT (используемый для панели Save As) - что необходимо выводить диалоговую панель с предупреждением, если пользователь выбирает для сохранения имя уже существующего файла.
Диалоговые панели выбора файлов обычно имеют список так называемых фильтров, включающих названия типов файлов и расширения имен файлов данного типа. Выбрав фильтр, пользователь указывает, что он желает работать только с файлами определенного типа, имеющими соответствующее расширение. Файлы с другими расширениями в диалоговых панелях не отображаются.
Список фильтров можно указать через параметр lpszFilter. Одновременно можно указать несколько фильтров. Каждый фильтр задается двумя строками - строкой, содержащей имя фильтра, и строкой, в которой перечислены соответствующие ему расширения имен файлов. Если одному типу соответствует несколько расширений, они разделяются символом ;. Строка, содержащая имя фильтра, отделяется от строки с расширениями файлов символом |. Если используется несколько фильтров, то они также отделяются друг от друга символом |. Например, в качестве строки, задающей фильтры, можно использовать строку вида:
Диалоговые панели, представленные объектами класса CFileDialog, могут иметь или не иметь родительского окна. Чтобы указать родительское окно, нужно передать конструктору CFileDialog указатель на него через параметр pParentWnd.
Методы класса CFileDialog
Создание объекта класса CFileDialog еще не вызывает отображения соответствующей диалоговой панели. Для этого необходимо воспользоваться методом DoModal класса CFileDialog.При вызове метода DoModal для ранее созданного объекта класса CFileDialog на экране открывается соответствующая диалоговая панель. После того, как пользователь завершает работу с диалоговой панелью, метод DoModal вернет значение IDOK или IDCANCEL в случае успешного завершения и нуль - в случае возникновения ошибок:
После того, как пользователь закроет диалоговую панель и метод DoModal вернет управление, можно воспользоваться другими методами класса CFileDialog , чтобы определить имена выбранных файлов:
GetPathName - Определяет полный путь файла
GetFileName - Определяет имя выбранного файла
GetFileExt - Определяет расширение имени выбранного файла
GetFileTitle - Позволяет определить заголовок выбранного файла
GetNextPathName - Если диалоговая панель позволяет выбрать сразу несколько файлов, то этот метод можно использовать для определения полного пути следующего из выбранных файлов
GetReadOnlyPref - Позволяет узнать состояние атрибута "только для чтения" (read-only) выбранного файла
GetStartPosition - Возвращает положение первого элемента из списка имен файлов
Наиболее важный метод - GetPathName. Он получает полный путь файла, выбранного из диалоговых панелей Open или Save As. Если диалоговая панель позволяет выбрать сразу несколько файлов, тогда метод GetPathName возвращает массив строк, состоящий из нескольких строк, заканчивающихся двоичным нулем. Первая из данных строк содержит путь к каталогу, в котором расположены выбранные файлы, остальные строки содержат имена выбранных файлов. Выделение строки, содержащей путь к каталогу, проблем не вызывает, а чтобы получить имена выбранных файлов, необходимо воспользоваться методами GetStartPosition и GetNextPathName.
[pagebreak]
Метод GetStartPosition возвращает значение типа POSITION. Оно предназначено для передачи методу GetNextPathName и получения очередного имени выбранного файла. Если пользователь не выбрал ни одного файла, метод GetStartPosition возвращает значение NULL. Значение, полученное этим методом, следует записать во временную переменную типа POSITION и передать ссылку на нее методу GetNextPathName. Метод GetNextPathName вернет полный путь первого из выбранных в диалоговой панели файлов и изменит значение переменной pos, переданной методу по ссылке. Новое значение pos можно использовать для последующих вызовов метода GetNextPathName и получения путей всех остальных выбранных файлов. Когда метод GetNextPathName вернет имена всех выбранных файлов, в переменную pos записывается значение NULL.
В панелях Open и Save As имеется переключатель "ReadOnly". По умолчанию этот преключатель не отображается. Если есть необходимость воспользоваться этим переключателем, то нужно отказаться от использования флага OFN_HIDEREADONLY.
Метод GetReadOnlyPref позволяет определить положение переключателя "ReadOnly". Если переключатель включен, то метод GetReadOnlyPref возвращает ненулевое значение. В противном случае GetReadOnlyPref возвращает нуль.
Панель выбора шрифта (класс CFontDialog)
Стандартная диалоговая панель Font предназначена для выбора шрифта. Эта панель отображает список шрифтов, установленных в системе, и позволяет выбрать название шрифта, его начертание и другие параметры.
Для управления диалоговой панелью Font в библиотеку классов MFC включен класс CFontDialog. Методы этого класса можно использовать для отображения панели Font и определения характеристик шрифта, выбранного пользователем. Конструктор класса CFontDialog:
Все параметры конструктора являются необязательными. Настройка стандартной панели выбора шрифта, которая выполняется конструктором класса CFontDialog по умолчанию, удовлетворяет большинству пользователей.
Параметр lplfInitial является указателем на структуру LOGFONT, описывающую логический шрифт. Если этот параметр используется, то в диалоговой панели по умолчанию будет выбран шрифт, наиболее соответствующий шрифту, описанному в структуре LOGFONT.
Параметр dwFlags задает набор флагов, управляющий различными режимами работы панели. Например, флаг CF_EFFECTS позволяет пользователю создавать подчеркнутые и перечеркнутые буквы, определять цвет букв, а флаг CF_SCREENFONTS - разрешает выбирать только экранные шрифты.
Через параметр pdcPrinter можно передать конструктору контекст отображения принтера, шрифты которого будут представлены в диалоговой панели Font. Данный параметр используется только в том случае, если в параметре dwFlags указаны флаги CF_PRINTERFONTS или CF_BOTH.
Через параметр pParentWnd можно указать родительское окно для диалоговой панели Font.
Методы класса CFontDialog
Для отображения диалоговой панели Font предназначен виртуальный метод DoModal. Если пользователь выбрал шрифт и нажал кнопку OK, метод DoModal возвращает идентификатор IDOK, если пользователь отменил выбор шрифта, метод DoModal возвращает идентификатор IDCANCEL:
Остальные методы класса предназначены для определения характеристик выбранного пользователем шрифта.
Метод GetCurrentFont позволяет сразу определить все характеристики выбранного шрифта, записав их в структуру LOGFONT.
Остальные методы класса позволяют определить только отдельные характеристики выбранного шрифта:
GetFaceName - Возвращает имя выбранного шрифта
GetStyleName - Возвращает имя стиля выбранного шрифта
GetSize - Возвращает размер выбранного шрифта
GetColor - Возвращает цвет выбранного шрифта
GetWeight - Возвращает плотность выбранного шрифта
IsStrikeOut - Определяет, является ли шрифт выделенным перечеркнутой линией
IsUnderline - Определяет, является ли шрифт выделенным подчеркиванием
IsBold - Определяет, является ли шрифт жирным
IsItalic - Определяет, является ли шрифт наклонным
Панель для вывода документов на печать (класс CPrintDialog)
Класс CPrintDialog можно использовать для создания двух видов диалоговых панелей, предназначенных для печати документов и выбора форматов документов. Кроме класса CPrintDialog можно также использовать класс CPageSetupDialog. Он позволяет создать диалоговую панель для выбора формата документа, имеющую несколько иной вид.
В приложениях, подготовленных с использованием средств MFC AppWizard и построенные по модели документ-облик, по умолчанию встроена возможность вывода редактируемого документа на печать.
В меню File такого приложения находятся три строки (Print, Print Preview и Print Setup), которые управляют процессом печати документов, подготовленных в приложении. Чтобы распечатать документ, достаточно выбрать из меню File строку Print. На экране появится диалоговая панель Print. В ней можно выбрать печатающее устройство для печати документов (группа Name), указать, будет печататься весь документ либо его часть (группа Print range), а также сколько копий документа будет напечатано (группа Copies). Также можно настроить различные характеристики печатающего устройства, если нажать кнопку Properties в группе Printer.
Если требуется определить только печатающее устройство и формат документа, из меню File следует выбрать строку Printer Setup. В группе Printer можно указать печатающее устройство и настроить его соответствующим образом. Группа Paper задает формат бумаги и режим подачи бумаги в печатающее устройство. Группа Orientation включает только один переключатель, определяющий ориентацию бумаги. Он принимает положение Portrait для вертикальной ориентации изображения на бумаге (режим "портрет") или Landscape для горизонтальной ориентации изоборажения на бумаге (режим "ландшафт").
Строка Print Preview меню File выбирается для предварительного просмотра документа перед печатью. При этом главное окно приложения изменит свой внешний вид и можно будет просмотреть, как будет выглядеть документ после печати.
Если не требуется выполнять специфическую обработку документа перед печатью, то вряд ли понадобится самостоятельное добавление программного кода, отвечающего за процесс печати. Просто следует отметить, что процедура создания панелей, связанных с печатью документа, практически ничем не отличается от создания выше описанных стандартных диалоговых панелей.
Панель для выполнения поиска и замены (класс CFindReplaceDialog)
Класс CFindReplaceDialog предназначен для управления диалоговыми окнами Find и Replace. Диалоговая панель Find используется для поиска известных строк в документе приложения, а панель Replace позволяет замену одной строки на другую.
Важным отличием диалоговых панелей Find и Replace от других стандартных диалоговых панелей является то, что они представляют собой немодальные диалоговые панели. Поэтому процесс создания этих панелей значительно отличается от процесса создания стандартных панелей для выбора цвета, шрифта и имен файла.
Выбор ключевых слов является одним из важнейших этапов оптимизации сайта под поисковые системы. Так как поисковики являются основным источником целевых посетителей, то этому вопросу надо уделять особое внимание. Правильно подобранные ключевые слова помогут пользователям легко находить страницы сайта, а также повысят их позицию в результатах выдачи по запросу.
Итак, для начала необходимо проанализировать тематику сайта и постараться взглянуть на него глазами посетителя. Цель такого упражнения-разминки – подбор слов и выражений, по которым, на ваш взгляд, производится поиск подобных сайтов.
Теперь можно приступить к детализации задачи, а именно, подбору ключевых слов для каждой страницы сайта отдельно. Большинство начинающих разработчиков при оптимизации допускают одну критическую ошибку, а именно, оптимизируют все страницы под одни и те же запросы. Они не учитывают тот факт, что машины поиска каждую страницу рассматривают независимо от остальных, поэтому необходимо оптимизировать страницы по отдельности, тщательно подбирая для них ключевые слова.
При анализе страницы необходимо написать около двух десятков ключевых слов, из которых попробовать сформировать фразы с учетом возможностей морфологического поиска и расположить слова и выражения в порядке их соответствия тематике страницы.
Например, ваша компания занимается продажей бытовой техники. Вместо использования в тегах HTML-кода и содержимом страниц ключевой фразы “продажа бытовой техники”, нужно уточнить эту фразу в зависимости от содержимого каждой страницы. Если на данной странице внимание сфокусировано, например, на кухонных комбайнах, то теги и текст необходимо оптимизировать именно под это выражение.
Сейчас идет тенденция к оптимизации страниц больше под ключевые выражения, чем под отдельные слова. Это связано с повышением уровня интернет-пользователей, которые для уточнения поисковых запросов из ключевых слов с помощью служебных символов строят ключевые фразы, значительно повышающие релевантность результатов поиска.
Следующий этап - это анализ частоты запросов по пунктам списка, составленного на этапе обдумывания тематики сайта. Здесь уже придется излагать не свое видение сайта, а вооружиться поисковой системой. Желательно брать тот поисковик, в трафике которого вы больше всего заинтересованы.
Составленный список предполагаемых ключевых слов можно проверить, например, с помощью сервиса «Яндекс.Директ» и выделить в нем фразы, сходные с заданными изначально. Далее необходимо посмотреть количество запросов для каждого выражения, выбранного на первом этапе, и попробовать найти фразы-синонимы. Если для них количество запросов будет больше, есть смысл заменить первоначальный вариант.
Чтобы выявить близкие по значению выражения, можно использовать сервис «Рамблер-Ассоциации», который представляет статистику поисковых запросов и работает по принципу «Те, кто ищут [запрос пользователя], ищут также». Сервис предназначен в помощь пользователю, совершившему поиск по какому-либо запросу и не получившему нужной информации. Статистика “ассоциаций” помогает выяснить интересы пользователей, путем анализа списка запросов, схожих с основным. Для выявления англоязычных запросов можно использовать сервис Wordtracker, который в бесплатной версии выдает ограниченные отчеты по поисковым запросам.
Теперь необходимо проанализировать полученную статистику запросов по списку ключевых слов. Если по некоторым из них результаты зашкаливают за десятки тысяч, их однозначно можно убрать из дальнейшего рассмотрения т.к. эти слова используются многими конкурентами. Здесь надо учесть тот факт, что если для оптимизации будет выбрана слишком распространенная ключевая фраза, то потребуется много времени и сил, чтобы взобраться на вершину ранжированного списка результатов. Кроме того, привлеченный таким образом сетевой трафик будет плохо сфокусирован, т.е. процент целевых покупателей будет невелик. С другой стороны, если для ключевой фразы будет получено малое число результатов, то эффективность такой оптимизации также буде невысока.
Чтобы добиться компромисса в этом сложном вопросе, надо брать ключевую фразу, которая является оптимальной для тематики страницы и высоко конкурентной, и добавлять в нее описательные слова или, например, конкретные модели и торговые марки, т.е. конкретизировать представленную на странице информацию.
Часто многие сайты для привлечения большего числа посетителей используют для ключевых слов практически на всех страницах выражения типа “все модели”, “весь модельный ряд”, “огромный выбор” и т.д. Если на вашем сайте в самом деле представлены все модели некоторой торговой марки или же подавляющее большинство их, то лучшим вариантом будет оптимизация под такой запрос какой-то одной страницы, например с самой популярной моделью. При этом на этой странице обязательно должны быть ссылки на другие модели или на страницу с кратким представлением всех моделей в удобном для сравнения виде. Если в ключевой фразе перечисляются конкретные модели, то необходимо располагать их в порядке убывания популярности.
Очень часто при вводе поискового запроса пользователи не пишут прописные буквы в названиях компаний, торговых марок, городов и т.п. Т.к. некоторые системы поиска чувствительны к регистру символов, т.е. поиск по вариантам фразы с символами, преобразованными в нижний регистр, и с символами в верхнем регистре приводит к разным результатам. Поэтому, чтобы улучшить результаты поиска своего сайта, надо добавлять на страницы все варианты написания ключевой фразы. Если во фразе используются слова, которые по правилам языка пишутся с прописной буквы, то можно использовать ее версию со строчными буквами там, где она не будет видна для посетителей.
В зависимости от того, под какую систему поиска оптимизируется сайт, необходимо узнать поддерживается ли ей морфологический поиск, т.е. поиск по слову во всех его морфологических формах. Это значит, что поиск по фразе «оптовая покупка скидка» может быть интерпретирован, как “при оптовой покупке скидки” и т.д. Чтобы определить, выполняет ли данный поисковик морфологическую функцию, можно проработать поиск по различным версиям ключевой фразы и проанализировать результаты.
Необходимо не только постоянно проводить мониторинг частоты использования вашей ключевой фразы пользователями, но и отслеживать, как много других страниц также оптимизированы под нее. Т.е. надо постоянно следить за конкурирующими ресурсами, которые стоят первыми в рейтинге при запросе по данной тематике.
Таким образом, выбор наиболее эффективных ключевых фраз может буквально поставить на ноги ваш онлайновый бизнес, а неудачный, наоборот, разрушить его. Главное не забывать, что каждая страница оптимизируется под одну-две ключевые фразы, которые четко соответствуют ее тематике.
Когда пишут про сокетное программирование, конечно же, подразумевается TCP/IP. Вот тут мы и отступим от правил, поговорим про IPX/SPX.
А все начинается как всегда, а именно, с инициализации WINSOCK библиотеки, обработка ошибок упускается для упрощения кода:
Ну и собственно сокет, тут я дам только кусок, отличный от нормальных сокетов:
В остальном, работа с SPX идентична работе TCP сокетов, все выше написанное справедливо и для IPX сокетов, только не забудьте, что последние нельзя законнектить. Открываются они следующим образом:
Передача данных происходит следующим образом:
Дальше я дам несколько, на мой взгляд, полезных вещей при работе с данными протоколами.
Приём заголовка пакета данных
В некоторых случаях нам нужен больший контроль над IPX/SPX пакетами, и для того, чтоб наше приложение могло управлять, изменять заголовок IPX/SPX, нужно вызвать следующий код:
А вот вам и структура заголовка SPX пакета, взято из WSIPX.H
В данном режиме Windows Sockets не будут сегментировать пакеты, ограничивая их размер до максимально допустимого протоколом.
Широковещательные пакеты
Широковещательные пакеты могут быть использованы, например, в качестве средства "принюхивания" клиента к серверу, это в случае, когда мы знаем порт нужного нам сервера, но не знаем его сетевого адресса.
Установка, изменение DataStreamType в заголовке SPX пакета
Это может быть использовано в собственных целях, например, для искусственной сегментации своих данных для совместимости разных реализаций протокола. Например, некоторые реализации протокола для DOS поддерживают максимальную длину пакета в 512 байт либо принудительно ограниченную сетевыми модулями, вот они и используют DataStreamType, чтобы указать последнюю порцию данных.
Устанавливается следующим образом:
Причём данную установку надо делать перед каждым send. Работает всё ОК, когда посылаются данные ДОС клиенту, ну а при приеме пакетов WIN клиентом от ДОС клиент DataStreamType не хочет устанавливатся, т.е. мы не получим установленное значение DataStreamType ДОС клиентом. Я обошел данную проблему при помощи следующего куска кода:
Данный метод хорош еще тем, что WIN клиент может принять один пакет вместо нескольких, посланных ДОС клиентом.
Другие специфические расширения для данных протоколов, используемые getsockopt/setsockopt, можно найти в файле wsnwlink.h, но, как упоминалось выше, данные расширения - для NT-платформ и могут не работать для других реализаций данных протоколов.
Часто встречающаяся ошибка при работе с сессией - поздний старт. Когда данные в браузер уже начали отправляться и вызов 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'].
Для программирования расширенных хранимых процедур Microsoft предоставляет ODS (Open Data Service) API набор макросов и функций, используемых для построения серверных приложений позволяющих расширить функциональность MS SQL Server 2000.
Расширенные хранимые процедуры - это обычные функции написанные на С/C++ с применением ODS API и WIN32 API, оформленные в виде библиотеки динамической компоновки (dll) и призванные, как я уже говорил, расширять функциональность SQL сервера. ODS API предоставляет разработчику богатый набор функций позволяющих передавать данные клиенту, полученные от любых внешних источников данных (data source) в виде обычных наборов записей (record set). Так же, extended stored procedure может возвращать значения через переданный ей параметр (OUTPUT parametr).
Как работают расширенные хранимые процедуры.
* Когда клиентское приложение вызывает расширенную хранимую процедуру, запрос передаётся в TDS формате через сетевую библиотеку Net-Libraries и Open Data Service ядру MS SQL SERVER.
* SQL Sever находит dll библиотеку ассоциированную с именем расширенной хранимой процедуры и загружает её в свой контекст, если она не была загружена туда ранее, и вызывает расширенную хранимую процедуру, реализованную как функцию внутри dll.
* Расширенная хранимая процедура выполняет на сервере необходимые ей действия и передаёт набор результатов клиентскому приложению, используя сервис предоставляемый ODS API.
Особенности расширенных хранимых процедур.
* Расширенные хранимые процедуры - это функции выполняющиеся в адресном пространстве MS SQL Server и в контексте безопасности учётной записи под которой запущена служба MS SQL Server;
* После того, как dll библиотека с расширенными хранимыми процедурами была загружена в память, она остаётся там до тех пор, пока SQL Server не будет остановлен, или пока администратор не выгрузит её принудительно, используя команду :
DBCC DLL_name (FREE).
* Расширенная хранимая процедура запускается на выполнение так же, как и обычная хранимая процедура:
EXECUTE xp_extendedProcName @param1, @param2 OUTPUT
@param1 входной параметр
@param2 входной/выходной параметр
Внимание!
Так как расширенные хранимые процедуры выполняются в адресном пространстве процесса службы MS SQL Server, любые критические ошибки, возникающие в их работе, могут вывести из строя ядро сервера, поэтому рекомендуется тщательно протестировать Вашу DLL перед установкой на рабочий сервер.
Создание расширенных хранимых процедур.
Расширенная хранимая процедура эта функция имеющая следующий прототип:
Параметр pSrvProc указатель на SRVPROC структуру, которая является описателем (handle) каждого конкретного клиентского подключения. Поля этой структуры недокументированны и содеражат информацию, которую библиотека ODS использует для управления коммуникацией и данными между серверным приложением (Open Data Services server application) и клиентом. В любом случае, Вам не потребуется обращаться к этой структуре и тем более нельзя модифицоравать её. Этот параметр требуется указывать при вызове любой функции ODS API, поэтому в дальнейшем я небуду останавливаться на его описании.
Использование префикса xp_ необязательно, однако существует соглашение начинать имя расширенной хранимой процедуры именно так, чтобы подчеркнуть отличие от обычной хранимой процедуры, имена которых, как Вы знаете, принято начинать с префикса sp_.
Так же следует помнить, что имена расширенных хранимых процедур чувствительны к регистру. Не забывайте об этом, когда будете вызвать расширенную хранимую процедуру, иначе вместо ожидаемого результата, Вы получите сообщение об ошибке.
Если Вам необходимо написать код инициализации/деинициализации dll, используйте для этого стандартную функцию DllMain(). Если у Вас нет такой необходимости, и вы не хотите писать DLLMain(), то компилятор соберёт свою версию функции DLLMain(), которая ничего не делает, а просто возвращает TRUE. Все функции, вызываемые из dll (т.е. расширенные хранимые процедуры) должны быть объявлены, как экспортируемые. Если Вы пишете на MS Visual C++ используйте директиву __declspec(dllexport). Если Ваш компилятор не поддерживает эту директиву, опишите экспортируемую функцию в секции EXPORTS в DEF файле.
Итак, для создания проекта, нам понадобятся следующие файлы:
* Srv.h заголовочный файл, содержит описание функций и макросов ODS API;
* Opends60.lib файл импорта библиотеки Opends60.dll, которая и реализует весь сервис предоставляемый ODS API.
Microsoft настоятельно рекомендует, чтобы все DLL библиотеки реализующие расширенные хранимые процедуры экспортировали функцию:
Когда MS SQL Server загружает DLL c extended stored procedure, он первым делом вызывает эту функцию, чтобы получить информацию о версии используемой библиотеки.
Для написания своей первой extended stored procedure, Вам понадобится установить на свой компьютер:
- MS SQL Server 2000 любой редакции (у меня стоит Personal Edition). В процесе инсталляции обязательно выберите опцию source sample
- MS Visual C++ (я использовал версию 7.0 ), но точно знаю подойдёт и 6.0
Установка SQL Server -a нужна для тестирования и отладки Вашей DLL. Возможна и отладка по сети, но я этого никогда не делал, и поэтому установил всё на свой локальный диск. В поставку Microsoft Visual C++ 7.0 редакции Interprise Edition входит мастер Extended Stored Procedure DLL Wizard. В принципе, ничего сверх естественного он не делает, а только генерирует заготовку шаблон расширенной хранимой процедуры. Если Вам нравятся мастера, можете использовать его. Я же предпочитаю делать всё ручками, и поэтому не буду рассматривать этот случай.
Теперь к делу:
- Запустите Visual C++ и создайте новый проект - Win32 Dynamic Link Library.
- Включите в проект заголовочный файл - #include <srv.h>;
- Зайдите в меню Tools => Options и добавьте пути поиска include и library файлов. Если , при установке MS SQL Server, Вы ничего не меняли, то задайте:
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsInclude для заголовочных файлов;
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsLib для библиотечных файлов.
- Укажите имя библиотечного файла opends60.lib в опциях линкера.
На этом подготовительный этап закончен, можно приступать к написанию своей первой extended stored procedure.
Постановка задачи.
Прежде чем приступать к программированию, необходимо чётко представлять с чего начать, какой должен быть конечный результат, и каким способом его добиться. Итак, вот нам техническое задание:
Разработать расширенную хранимую процедуру для MS SQL Server 2000, которая получает полный список пользователей зарегистрированных в домене, и возвращает его клиенту в виде стандартного набора записей (record set). В качестве первого входного параметра функция получает имя сервера содержащего базу данных каталога (Active Directory), т.е имя контролера домена. Если этот параметр равен NULL, тогда необходимо передать клиенту список локальных групп. Второй параметр будет использоваться extended stored procedure для возварата значения результата успешной/неуспешной работы (OUTPUT параметр). Если, расширенная хранимая процедура выполнена успешно, тогда необходимо передать количество записей возвращённых в клиентский record set , если в процессе работы не удалось получить требуемую информацию, значение второго параметра необходимо установить в -1, как признак неуспешного завершения.
.
А вот шаблон расширенной хранимой процедуры, который нам предстоит наполнить содержанием:
Работа с входными параметрами
В этой главе я не хочу рассеивать Ваше внимание на посторонних вещах, а хочу сосредоточить его на работе с переданными в расширенную хранимую процедуру параметрами. Поэтуму мы несколько упростим наше техническое задание и разработаем тольку ту его часть, которая работает с входными параметрами. Но сначал не много теории
Первое действие, которое должна выполнить наша exteneded stored procedure , - получить параметры, которые были переданы ей при вызове. Следуя приведённому выше алгоритму нам необходимо выполнить следующие действия:
- Определить кол-во переданных параметров;
- Убедится, что переданные параметры имеют верный тип данных;
- Убедиться, что указанный OUTPUT параметр имеет достаточную длину, для сохранения в нём значения возвращаемого нашей extended stored procedure.
- Получить переданные параметры;
- Установить значения выходного параметра как результат успешного/неуспешного завершения работы extended stored procedure .
Теперь рассмотрим подробно каждый пункт:
Определение количества переданных в расширенную хранимую процедуру параметров
Для получения количества переданных параметров необходимо использовать функцию:
.
При успешном завершении функция возвращает количество переданных в расширенную хранимую процедуру параметров. Если extended stored procedure была вызвана без параметров - srv_rpcparams ввернёт -1. Параметры могут быть переданы по имени или по позиции (unnamed). В любом случае, нельзя смешивать эти два способа. Попытка передачи в функцию входных параметров по имени и по позиции одновременно - приведёт к возникновению ошибки, и srv_rpcparams вернёт 0 .
[pagebreak]
Определение типа данных и длины переданых параметров
Для получения информации о типе и длине переданных параметров Microsoft рекомендует использовать функцию srv_paramifo. Эта универсальная функция заменяет вызовы srv_paramtype, srv_paramlen, srv_parammaxlen, которые теперь считаются устаревшими. Вот её прототип:
.
.
.
.
.
.
.
.
.
.
pByte - указатель на переменную получающую информацию о типе входного параметра;
pbType задаёт порядковый номер параметра. Номер первого параметра начинается с 1.
pcbMaxLen - указатель на переменную, в которую функция заносит максимальное значение длины параметра. Это значение обусловлено конкретным типом данных переданного параметра, его мы и будем использовать, чтобы убедиться втом, что OUTPUT параметр имеет достаточную длину для сохранения передаваемых данных.
pcbActualLen указатель на реальную длину параметра переданного в расширенную хранимую процедуру при вызове. Если передаваемый параметр имеет нулевую длину, а флаг pfNull устанавлен в FALSE то (* pcbActualLen) ==0.
pbData - указатель на буфер, память для которого должна быть выделена перед вызовом srv_paraminfo. В этом буфере функция размещает полученные от extended stored procedure входные параметры. Размер буфера в байтах равен значению pcbMaxLen. Если этот параметр установлен в NULL, данные в буфер не записываются, но функция корректно возвращает значения *pbType, *pcbMaxLen, *pcbActualLen, *pfNull. Поэтому вызывать srv_paraminfo нужно дважды: сначала с pbData=NULL, потом, выделив необходимый размер памяти под буфер равный pcbActualLen, вызвать srv_paraminfo второй раз, передав в pbData указатель на выделенный блок памяти.
pfNull указатель на NULL-флаг. srv_paraminfo устанавливает его в TRUE, если значение входного параметра равно NULL.
Проверка, является ли второй параметр OUTPUT параметром.
Функция srv_paramstatus() предназначена для определения статуса переданного параметра:
.
.
.
.
.
n - номер параметра переданного в расширенную хранимую процедуру при вызове. Напомню: параметры всегда нумеруются с 1.
Для возврата значения, srv_paramstatus использует нулевой бит. Если он установлен в 1 переданный параметр является OUTPUT параметром, если в 0 обычным параметром, переданным по значению. Если, exteneded stored procedure была вызвана без параметров, функция вернёт -1.
Установка значения выходного параметра.
Выходному параметру, переданному в расширеную хранимую можно передать значение используя функцию srv_paramsetoutput. Эта новая функция заменяет вызов функции srv_paramset, которая теперь считается устаревашай, т.к. не поддерживает новые типы данных введённые в ODS API и данные нулевой длины.
.
.
.
.
.
.
.
.
n - порядковый номер параметра, которому будет присвоено новое значение. Это должен быть OUTPUT параметр.
pbData указатель на буфер с данными, которые будут посланы клиенту для установки значения выходного параметра.
cbLen длина буфера посылаемых данных. Если тип данных переданного OUTPUT параметра определяет данные постоянной длины и не разрешает хранение значения NULL (например SRVBIT или SRVINT1), то функция игнорирует параметр cbLen. Значение cbLen=0 указывает на данные нулевой длины, при этом парметр fNull должен быть установлен в FALSE.
fNull установите этот его в TRUE, если возвращаемому параметру необходимо присвоить значение NULL, при этом значение cbLen должно быть равно 0, иначе функция завершится с ошибкой. Во всех остальных случаях fNull=FALSE.
В случае успешного завершения функция возвращает SUCCEED. Если возвращаемое значение равно FAIL, значит вызов был неудачным. Всё просто и понятно
Теперь мы достаточно знаем, для того чтобы написать свою первую расширенную хранимую процедуру, которая будет возвращать значение через переданный ей параметр.Пусть, по сложившейся традиции, это будет строка Hello world! Отладочну версию примера можно скачать здесь.
. Не рассмотренными остались функции srv_sendmsg и srv_senddone. Функция srv_sendmsg используется для посылки сообщений клиенту. Вот её прототип:
msgtype определяет тип посылаемого клиенту сообщения. Константа SRV_MSG_INFO обозначает информационное сообщение, а SRV_MSG_ERROR сообщение об ошибке;
msgnum номер сообщения;
class - степень тяжести возникшей ошибки. Информационные сообщения имеют значение степени тяжести меньшее или равное 10;
state номер состояния ошибки для текущего сообщения. Этот параметр предоставляет информацию о контексте возникшей ошибки. Допустимые значения лежат в диапазоне от 0 до 127;
rpcname в настоящее время не используется;
rpcnamelen - в настоящее время не используется;
linenum здесь можно указать номер строки исходного кода. По этому значению, в последствие будет легко установить в каком месте возникла ошибка. Если Вы не хотите использовать эту возможность, тогда установите linenum в 0;
message указатель на строку посылаемую клиенту;
msglen определяет длину в байтах строки сообщения. Если это строка заканчивается нулевым символом, то значение этого параметра можно установить равным SRV_NULLTERM.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
В процессе работы расширенная хранимая процедура должна регулярно сообщать клиентскому приложению свой статус, т.е. посылать сообщения о выполненных действиях. Для этого и предназначена функция srv_senddone:
status - статус флаг. Значение этого параметра можно задавать использую логические операторы AND и OR для комбинирования констант приведённых в таблице:
Status flag Описание
SRV_DONE_FINAL Текущий набор результатов является окончательным;
SRV_DONE_MORE Текущий набор результатов не является окончательным следует ожидать очердную порцию данных;
SRV_DONE_COUNT Параметр count содержит верное значение
SRV_DONE_ERROR Используется для уведомления о возникновении ошибок и немедленном завершении.
into зарезервирован, необходимо установить в 0.
count количество результирующих наборов данных посылаемых клиенту. Если флаг status установлен в SRV_DONE_COUNT, то count должен содержать правильное количество посылаемый клиенту наборв записей.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
Установка расширенных хранимых процедур на MS SQL Server 2000
1.Скопируйте dll библиотеку с расширенной хранимой процедурой в каталог binn на машине с установленным MS SQL Server. У меня этот путь следующий: C:Program FilesMicrosoft SQL ServerMSSQLBinn;
2.Зарегистрирйте расширенную хранимую процедуру на серверt выполнив следующий скрипт:
Заключение
На этом первая часть моей статьи закончена. Теперь я уверен Вы готовы справиться с нашим техническим заданием на все 100%. В следующей статье Вы узнаете:
- Типы данных определённые в ODS API;
- Особенности отладки расширенных хранимых процдур;
- Как формировать recordset-ы и передавать их клиентскому приложению;
- Чстично мы рассмотрим функции Active Directory Network Manegment API необходимые для получения списка доменных пользователей;
- Создадим готовый проект (реализуем наше техническое задание)
Надеюсь - до скорой встречи!
Поиск
