Глава 2 Канальный уровень

Введение

Ethernet и IEEE 802 инкапсуляция

Рисунок 2.1 Инкапсуляция IEEE 802.2/802.3 (RFC 1042) и инкапсуляция Ethernet (RFC 894).

На рисунке 2.5 приведен список некоторых типичных значений MTU, взятых из RFC 1191 . Здесь приведены MTU для каналов точка-точка (таких как SLIP или PPP), однако они не являются физической характеристикой среды передачи. Это логическое ограничение, при соблюдении которого обеспечивается адекватное время отклика при диалоговом использовании. В разделе главы 2 мы рассмотрим, откуда берется это ограничение.

В разделе "Команда netstat" главы 3 мы воспользуемся командой netstat, чтобы определить MTU для определенного интерфейса.

Рисунок 2.5 Типичные значения максимальных блоков передачи (MTU).

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

Транспортный MTU между любыми двумя хостами может быть не постоянным. MTU зависит от загруженности канала на настоящий момент. Также он зависит от маршрута. Маршрут может быть несимметричным (маршрут от A до B может быть совсем не тем, что маршрут от B к A), поэтому MTU может быть неодинаков для этих двух направлений.

RFC 1191 описывает механизм определения транспортного MTU (path MTU discovery mechanism). Мы рассмотрим как функционирует этот механизм после того, как опишем фрагментацию ICMP и IP. В разделе "ICMP ошибки о недоступности" главы 11 мы подробно рассмотрим ошибку недоступности ICMP, которая используется в этом механизме, а в разделе "Определение транспортного MTU с использованием Traceroute" главы 11 мы покажем версию программы traceroute, которая использует механизм определения транспортного MTU до пункта назначения. В разделах "Определение транспортного MTU при использовании UDP" главы 11 и "Определение транспортного MTU" главы 24 показано, как функционируют UDP и TCP, когда реализация поддерживает определение MTU.

Если скорость в линии составляет 9600 бит/сек, при этом 1 байт составляет 8 бит плюс 1 старт-бит и 1 стоп-бит, скорость линии будет 960 байт/сек. Передача пакета размером 1024 байта с этой скоростью займет 1066 мс. Если мы используем SLIP канал для диалогового приложения и одновременно с ним работает такое приложение как FTP, которое посылает или принимает пакеты по 1024 байт, мы должны ждать, так как среднее время задержки нашего интерактивного пакета составит 533 мс.

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

Ожидание в 533 мс неприемлемо для диалогового ответа. С точки зрения человеческого фактора мы знаем, что неприемлемой является задержка дольше чем 100-200 мс [ Jacobson 1990a]. Под задержкой подразумевается время между отправкой пакета и возвращением отклика (как правило, эхо символа).

Уменьшение MTU в канале SLIP до 256 означает, что максимальное время, в течение которого канал может быть занят одним фреймом, составляет 266 мс, и половина от этого (наше среднее время ожидания) составляет 133 мс. Это лучше, однако до сих пор не идеально. Причина, по которой мы выбрали это значение (как сравниваются 64 и 128), заключается в том, чтобы обеспечить лучшее использование канала для передачи данных (как, например, при передаче большого файла). В случае CSLIP фрейма размером 261 байт с заголовком размером в 5 байт (256 байт данных), 98,1% линии используются для передачи данных и 1,9% на заголовки. Уменьшение MTU меньше чем 256 уменьшает максимальное значение пропускной способности линии, которую мы можем получить при передаче данных.

Значение MTU равное 296 для канала точка-точка (рисунок 2.5), подразумевает 256 байт данных и 40 байт TCP и IP заголовков. Так как MTU это величина, о которой IP узнает от канального уровня, это значение должно включать в себя стандартные заголовки TCP и IP. Именно таким образом IP принимает решение о фрагментации. IP ничего не знает о сжатии заголовков, которое осуществляются CSLIP.

Наш расчет средней задержки (половина того времени, которое требуется на передачу фрейма максимального размера) имеет отношение только к каналу SLIP (или каналу PPP), который используется для передачи интерактивного трафика и трафика данных. Когда идет обмен только интерактивным трафиком, время передачи одного байта данных в каждом направлении (в случае сжатого 5-байтового заголовка) составляет примерно 12,5 мс, при скорости 9600 бит/сек. Это хорошо укладывается в диапазон 100-200 мс, о котором мы упоминали ранее. Также заметьте, что сжатие заголовков с 40 до 5 байт уменьшает время задержки для одного байта с 85 до 12,5 мс.

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

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

В этой главе рассматривался самый нижний уровень из семейства протоколов Internet, канальный уровень. Мы рассмотрели различие между Ethernet и IEEE 802.2/802.3 инкапсуляциями, и инкапсуляцию, которая используется в SLIP и PPP. Так как оба SLIP и PPP часто используются на медленных каналах, они предоставляют методы, для сжатия общих полей (которые практически всегда неизменны). При этом улучшается время отклика.

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

Мы описали важную характеристику большинства канальных уровней, MTU и соответствующую концепцию транспортного MTU. Используя стандартный MTU для последовательных линий, мы вычислили временную задержку, которая существует в каналах SLIP и CSLIP.

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

Организация канального уровня

Важнейшими задачами, решаемыми канальным уровнем модели сетевого взаимодействия (иногда этот уровень называют уровнем передачи данных ), являются задачи предоставления определенных сервисов сетево­му уровню. Основным сервисом является передача данных от сетевого уровня пе­редающей вычислительной машины сетевому уровню принимающей машины. На передающей ма­шине работает процесс, который передает биты с сетевого уровня на канальный уровень для передачи их по назначению. Работа канального уров­ня заключается в передаче этих битов на принимающую маши­ну так, чтобы они могли быть переданы сетевому уровню принимающей машины. Физически данные передаются по реальным каналам передачи, как схематично пока­зано на рис. 8.1.а. Однако посредством протоколов канального уровня виртуальный путь передачи данных связывает канальные уровни пе­редающей и принимающей вычислительной машины (рис. 8.1.б ).

Рис. 8.1. Пути передачи данных: а – виртуальный; б – фактический

Протоколы канального уровня описывают, каким образом логические биты или символы, передаваемые физическим уровнем, объединяются в более крупные единицы – кадры . Обобщенная структура кадра показана на рис. 8.2. В общем случае, каждый кадр содер­жит заголовок, поле данных и трейлер (или так называемый «концевик» ). Управление кадрами – одна их главнейших функций работы канального уровня.

Рис. 8.2. Обобщенная структура кадра протокола канального уровня

Канальный уровень может предоставлять различные сервисы и их на­бор может быть разным для разных систем. Обычно рассматриваются следующие возможные вари­анты:

1) сервис без подтверждений приема кадров и без установления соединения;

2) сервис с подтверждениями приема кадров и без установления соединения;

3) сервис с подтверждениями приема кадров и с установлением соединения.

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

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

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

Для предоставления сервиса сетевому уровню канальный уровень должен использовать сервисы, предоставляемые ему физическим уровнем. Физический уровень принимает необработанный поток битов и пытается передать его по на­значению. Этот поток не застрахован от ошибок. Количество принятых битов мо­жет быть меньше, равно или больше числа переданных бит. Кроме того, значения принятых битов могут отличаться от значений переданных. Канальный уровень должен обнаружить ошибки и, если нужно, исправить их.

Обычно канальный уровень разбивает поток битов на отдельные кадры и считает для каждого кадра так называемую контрольную сумму. Когда кадр прибывает в пункт назначения, его контрольная сумма подсчитывается снова. Если она отличается от содержащейся в кадре, то канальный уровень «понимает», что при переда­че кадра произошла ошибка, и принимает соответствующие меры (например, игнорирует испор­ченный кадр и посылает передающей машине сообщение об ошибке). Разбиение потока битов на отдельные кадры представляет собой не очень простую задачу. Один из способов раз­биения на кадры заключается во вставке временных интервалов между кадрами, подобно тому, как вставляются пробелы между словами в тексте. Однако сети редко предоставляют гарантии сохранения временных интервалов при передаче данных, поэтому возможно, что эти интервалы при передаче исчезнут или, на­оборот, будут добавлены новые интервалы. Поэтому для повышения надежности передачи данных предложены более совершенные методы. Среди них наиболее популярны такие методы маркировки границ кадров (формирования кадров ), как:

1) подсчет количества символов;

2) применение сигнальных байтов с символьным заполнением;

3) использование стартовых и стоповых битов с битовым заполнением;

4) использование запрещенных сигналов физического уровня.

Первый метод формирования кадров использует поле в заголовке для указа­ния количества символов в кадре. Когда канальный уровень на принимаю­щей машине видит это поле, он узнает, сколько символов последует, и таким образом определяет, где находится конец кадра. Недостаток такого метода заключается в том, что при передаче может быть искажен сам счетчик. Тогда принимающая машина потеряет синхронизацию и не сможет обнаружить начало следующего кадра. Даже если контрольная сумма не совпадет и принимающая машина «пой­мет», что кадр принят неверно, то она все равно не сможет определить, где начало следующего кадра. Запрашивать повторную передачу кадра также бесполезно, поскольку принимающая машина не «знает», сколько символов нужно пропус­тить до начала повторной передачи. По этой причине метод подсчета символов теперь практически не применяется.

Второй метод формирования кадров решает проблему восстановления син­хронизации после сбоя при помощи маркировки начала и конца каждого кадра специальными байтами. В последнее время большинство протоколов перешло на использова­ние в обоих случаях одного и того же байта, называемого флаговым . Таким образом, если приемник теряет синхронизацию, ему необходимо просто найти флаговый байт, с помощью которого он распозна­ет конец текущего кадра. Два соседних флаговых байта говорят о том, что кон­чился один кадр и начался другой. Однако этот метод иногда приводит к серьезным проблемам при передачи бинарных данных, таких как объектные коды программ или числа с плавающей запятой. В передаваемых данных вполне может встретиться последовательность, исполь­зуемая в качестве флагового байта. Возникновение такой ситуации, скорее всего, собьет синхронизацию. Одним из способов решения проблемы является добав­ление специального escape-символа (знака переключения кода – ESC ) непосред­ственно перед байтом, случайно совпавшим с флаговым байтом внутри кадра. Канальный уровень получателя вначале убирает эти escape-символы, затем переда­ет кадр на сетевой уровень. Этот метод называется символьным заполнением. Таким образом, настоящий флаг можно отличить от «случайно совпавшего» по наличию или отсутствию перед ним символа ESC. Если же и символ ESC случайно окажется среди прочих данных, то перед этим фиктивным escape-символом также вставляется настоящий. Тогда любой одиночный ESC будет частью escape-после­довательности, а двойной будет указывать на то, что служебный байт случайно оказался в потоке данных. После очищения от вставных символов байтовая последовательности в точности совпадает с исходной. Главный недостаток этого метода заключается в том, что он тесно связан с 8-битными символами. Между тем не во всех кодировках один символ соответ­ствует 8 битам. Например, кодировка UNICODE использует 16-битное кодирование.

Следующий метод позволяет использовать кадры и наборы символов, состоящие из любого количества битов. При этом каждый кадр начинается и завершается специальной последовательностью битов 01111110. Битовое заполнение аналогично символьному, при котором в кадр перед случайно встретившимся среди данных флагом вставляется escape-символ. Битовое заполнение, как и сим­вольное, является абсолютно прозрачным для сетевого уровня обеих машин. Если флаговая последовательность битов (01111110) встречается в данных пользователя, она передается в виде 011111010, но в памяти принимающего ком­пьютера сохраняется опять в исходном виде: 01111110. Благодаря битовому заполнению границы между двумя кадрами могут быть безошибочно распознаны с помощью флаговой последовательности. Таким образом, если приемная сторона потеряет границы кадров, ей нужно всего лишь оты­скать в полученном потоке битов флаговый байт, поскольку он встречается толь­ко на границах кадров и не может присутствовать в данных пользователя.

Наконец, последний из рассматриваемых методов формирования кадров приемлем только в сетях, в которых физический носитель обладает некоторой избыточностью. Например, некоторые локальные сети кодируют один бит данных двумя физическими бита­ми. Так в «манчестерском» коде бит 1 кодируется парой высокого и низкого уровней сигналов (от­рицательный перепад), а бит 0 – наоборот, парой низкого и высокого уровней (положительный перепад). В такой схеме каждый передаваемый бит данных со­держит в середине переход, благодаря чему упрощается распознавание границ битов. Комбинации уровней сигналов (низкий–низкий и высокий–высокий) не используются для передачи данных, но используются в качестве ограничителей кадров в некоторых протоколах.

Отметим, что многие современные протоколы пе­редачи данных для повышения надежности применяют комбинированные методы формирования кадра.

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

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

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

Стандарт ANSI С расширяет концепцию предварительного описания функции. Данное расширенное описание называется прототипом функции.

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

тип имя_функции (список параметров);

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

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

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

/* Данная программа использует прототипы функций для достижения строгой проверки типов при вызове func(). Программа не компилируется из-за несоответствия между типом аргументов, определенных в прототипе функции, и типом аргументов, используемых при вызове функции. */

#include

int main(void)
{
int x, *y;
x = 10;
у = &x;
func(x, у) ; /* несоответствие типов */
return 0;
}

Float func (int x, float y)
{
printf("%f", у/(float)x);
return у/(float) x;
}

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

/* Программа не компилируется из-за несоответствия между числом параметров, определенных в прототипе функции, и числом аргументов, используемых при вызове функции. */

#include
float func (int x, float у); /* прототип */
int main(void)
{
func (2, 2.0, 4); /* неверное число аргументов */
return 0;
}

Float func {int x, float y)
{
printf ("%f", у/(float)x);
return у/(float) x;
}

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

Char func (char *, int);

Char func (char *str, int count);

Тем не менее, если включить имена параметров, компилятор использует имена для выдачи сообщений о несоответствии типов.

Некоторые функции типа printf() могут принимать переменное число аргументов. Переменное число аргументов определяется в прототипе с помощью многоточия. Например, прототип функции printf() выглядит так:

Int printf(const char *fmt, ...);

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

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

В современных, правильно написанных программах на языке С каждую функцию перед использованием необходимо объявлять. Обычно это делается с помощью прототипа функции . В первоначальном варианте языка С прототипов не было; но они были введены уже в Стандарт С89. Хотя прототипы формально не требуются, но их использование очень желательно. (Впрочем, в C++ прототипы обязательны !) Во всех примерах этой книги имеются полные прототипы функций. Прототипы дают компилятору возможность тщательнее выполнять проверку типов, подобно тому, как это делается в таких языках как Pascal. Если используются прототипы, то компилятор может обнаружить любые сомнительные преобразования типов аргументов, необходимые при вызове функции, если тип ее параметров отличается от типов аргументов. При этом будут выданы предупреждения обо всех таких сомнительных преобразованиях. Компилятор также обнаружит различия в количестве аргументов, использованных при вызове функции, и в количестве параметров функции.

В общем виде прототип функции должен выглядеть таким образом:

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

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

/* В этой программе используется прототип функции чтобы обеспечить тщательную проверку типов. */ void sqr_it(int *i); /* прототип */ int main(void) { int x; x = 10; sqr_it(x); /* несоответствие типов */ return 0; } void sqr_it(int *i) { *i = *i * *i; }

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

#include /* Это определение будет также служить и прототипом внутри этой программы. */ void f(int a, int b) { printf("%d ", a % b); } int main(void) { f(10,3); return 0; }

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

Единственная функция, для которой не требуется прототип - это main() , так как это первая функция, вызываемая в начале работы программы.

Имеется небольшая, но важная разница в том, как именно в С и C++ обрабатывается прототип функции, не имеющей параметров. В C++ пустой список параметров указывается полным отсутствием в прототипе любых параметров. Например,

Int f(); /* Прототип C++ для функции, не имеющей параметров */

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

Если функция в языке С не имеет параметров, то в ее прототипе внутри списка параметров стоит только ключевое слово void . Вот, например, прототип функции f() в том виде, в каком он должен быть в программе на языке С:

Float f(void);

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

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

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

Старомодные объявления функций

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

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

#include double div(); /* старомодное объявление функции */ int main(void) { printf("%f", div(10.2, 20.0)); return 0; } double div(double num, double denom) { return num / denom; }

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

Общий вид старомодного оператора объявления функции такой:

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

Как уже говорилось, старомодное объявление функции устарело и не должно использоваться в новом коде. Кроме того, оно несовместимо с C++.

Прототипы старомодных библиотечных функций

Любая стандартная библиотечная функция в программе должна иметь прототип. Поэтому для каждой такой функции необходимо ввести соответствующий заголовок. Все необходимые заголовки предоставляются компилятором С. В системе программирования на языке С библиотечными заголовками (обычно) являются файлы, в именах которых используется расширение.h . В заголовке имеется два основных элемента: любые определения, используемые библиотечными функциями, и прототипы библиотечных функций. Например, почти во все программы из этой книги включается файл , потому что в этом файле находится прототип для printf() . Заголовки для стандартных функций описаны в