4 Сетевое программирование: сетевые утилиты


Скачать 258.02 Kb.
Название4 Сетевое программирование: сетевые утилиты
Дата публикации09.10.2014
Размер258.02 Kb.
ТипДокументы
referatdb.ru > Информатика > Документы




Тема 4 Сетевое программирование: сетевые утилиты Сетевые протоколы- протокол IP. Сопоставление адреса ARP и RARP. Транспортные протоколы –протокол UDP. Протокол TCP. Прикладные протоколы NetBios. Протокол IPX/SPX. Сканер портов. Почтовые утилиты.
Основы программирования сети

I. модель взаимодействия открытых систем (OSI- Open Systems Interconnection), которая была разработана Международной организацией по стандартам (ISO, International Organization for Standardization). В соответствии с этой моделью сетевое взаимодействие делится на семь уровней:

  1. ^ Физический уровень- передача битов по физическим каналам (коаксиальный кабель, витая пара, оптоволоконный кабель). Здесь определяются характеристики физических сред и параметры электрических сигналов.

  2. ^ Канальный уровень- передача кадра данных между любыми узлами в сетях типовой топологии или соседними узлами произвольной топологии. В качестве адресов на канальном уровне используются МАС- адреса.

  3. Уровень сети- доставка пакета любому узлу в сетях произвольной топологии. На этом уровне нет никаких гарантий доставки пакета.

  4. ^ Уровень транспорта- доставка пакета любому узлу с любой топологией сети и заданным уровнем надежности доставки. На этом уровне имеются средства для установления соединения, буферизации, нумерации и упорядочивания пакетов.

  5. ^ Уровень сеанса- управление диалогом между узлами. Обеспечена возможность фиксации активной на данный момент стороны.

  6. Уровень представления- здесь возможно задать преобразование данных (шифрование, сжатие).

  7. ^ Прикладной уровень- набор сетевых сервисов (FTP, E- mail и др.) для пользователя и приложения.

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

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

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

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

Чем ниже находится протокол (ближе к прикладному уровню), тем больше у него возможностей и больше накладных расходов при передаче данных (больше и сложнее заголовок). Рассматриваемые сегодня протоколы будут находиться на разных уровнях, поэтому будут иметь разные возможности.
MS TCP/IP Справочная модель OSI

Уровень приложения

Сокеты Windows

NetBIOS
NetBIOS на основе TCP/IP

Уровень приложения

Уровень представления

Интерфейс TDI

Уровень сеанса

Уровень транспорта

UDP

TCP

Уровень транспорта

Межсетевой уровень

ICMP ARP

^ IP

IGMP RARP


Уровень сети

Интерфейс NDIS

Уровень сетевого интерфейса

Internet
FDDI

Драйверы сетевых карт

PPP
Трансляция пакета данных


Канальный уровень
Физический уровень

Сетевые карты


Рис.4.1. Модель OSI и вариант от MS

Корпорация Microsoft как всегда пошла своим путем и реализовала модель OSI в TCP/IP по- своему. Я понимаю, что модель OSI справочная и предназначена только в качестве рекомендации, но нельзя же было так ее изменять, ведь принцип оставлен тот же, хотя изменились названия и количество уровней.

У Microsoft вместо семи уровней есть только четыре. Но это не значит, что остальные уровни позабыты и позаброшены, просто один уровень Microsoft может выполнять все, что в OSI делают три уровня. Например, уровень приложения у Microsoft выполняет все, что делают уровень приложения, уровень представления и уровень сеанса вместе взятые.

На рис. 4.1 графически сопоставлена модель MS TCP и справочная модель OSI. Слева указаны названия уровней по методу MS, а справа- уровни OSI. В центре указаны протоколы. Они размещены именно на том уровне, на котором они работают.

^ Сетевые протоколы- протокол IP.

Некоторые считают, что протокол TCP/IP- это одно целое. На самом деле это два разных протокола, которые работают совместно. Опишем подробно разницу в протоколах.

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

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

Каждый IP- пакет содержит адреса отправителя и получателя, идентификатор протокола, TTL (время жизни пакета) и контрольную сумму для проверки целостности пакета. Как видно здесь есть контрольная сумма, которая все же позволяет узнать целостность пакета. Но об этом узнает только получатель. Когда компьютер- получатель принимает пакет, то он проверяет контрольную сумму только для себя. Если сумма сходится, то пакет обрабатывается, иначе просто сбрасывается. А компьютер отправитель пакета не сможет узнать об ошибке, которая возникла в пакете, и не сможет заново отправить пакет. Именно поэтому соединение по протоколу IP нельзя считать надежным.
^ Сопоставление адреса ARP и RARP

Протокол ARP (Address Resolution Protoсol, протокол определения адреса) предназначен для определения аппаратного (MAC) адреса компьютера в сети по его IP- адресу. Прежде чем данные смогут быть отправлены на какой- нибудь компьютер, отправитель должен знать аппаратный адрес получателя. Именно для этого и предназначен ARP.

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

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

Чтобы вам легче было ориентироваться, скажу еще, что широковещательные пакеты могут пересылаться по коаксиалу (потому что здесь отсутствуют хабы и коммутаторы), а при использовании витой пары- через хабы и простые коммутаторы. Если компьютер расположен в другой сети, то его поиск происходит немного по другой схеме. Если вы хотите узнать об этом подробнее, то советую почитать дополнительную документацию, которую я выложил на диске в разделе Документация или на моем сайте в разделе Сети.
Протокол RARP (Reverse Address Resolution Protocol, обратный протокол определения адреса) делает обратное- определяет IP- адрес по известному МАС- адресу. Процесс поиска адресов абсолютно такой же.
Транспортное протоколы- быстрый UDP.

На транспортном уровне мы имеем два протокола: UDP и TCP. Оба они работают поверх IP. Это значит, что когда пакет TCP или UDP опускается на уровень ниже для отправки в сеть? Он попадает на уровень сети прямо в лапы протокола IP№ Здесь пакету добавляется сетевой адрес? TTL и другие атрибуты протокола IP. После этого пакет идет дальше вниз для физической отправки в сеть. Голый пакет TCP не может быть отправлен в сеть, потому что он не имеет информации о получателе, эта информация добавляется к пакету с IP- заголовком на уровне сети.

Рассмотрим каждый протокол в отдельности, и начнем мы с UDP. Как и IP, протокол UDP для передачи данных не устанавливает соединения с сервером. Данные просто выбрасываются в сеть, и протокол даже не заботится о доставке пакета. Если данные на пути к серверу испортятся или вообще не дойдут, то отправляющая сторона об этом не узнает. Так что по этому протоколу, как и по голому IP, не желательно передавать очень важные данные.

Благодаря тому что протокол UDP не устанавливает соединения, он работает очень быстро ( в несколько раз быстрее ТСР). Из-за высокой скорости его очень удобно использовать там, где данные нужно передавать быстро и не нужно заботиться об их целостности. Примером могут служить радиостанции в Интернете. Звуковые данные просто впрыскиваются в глобальную сеть, и если слушатель не получит одного пакета, то максимум что он заметит- небольшое заикание в месте потери. Но если учесть, что сетевые пакеты имеют не большой размер, то заикание будет сложно заметить.

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

Итак, UDP очень быстр, но его можно использовать только там, где данные не имеют высокой ценности (возможна потеря отдельных пакетов) и не имеют секретности (UDP больше подвержен взлому).
^ Медленный, но надежный ТСР

Как было ранее указано, что протокол NCH лежит на одном уровне с UDP и работает поверх IP (для отправки данных используется IP). Именно поэтому протоколы NCH и IP часто объединяют одним названием ТСР/IP, так как ТСР неразрывно связан с IP.

В отличие от UDP протокол ТСР устраняет недостатки своего транспорта (IP). В этом протоколе заложены средства установления связи между приемником и передатчиком, обеспечение целостности данных и гарантии их доставки.

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

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

Из-за лишних накладных расходов на установку соединения, подтверждения доставки и повторную пересылку испорченных данных протокол ТСР намного медленней UDP. Зато ТСР можно использовать там, где нужна гарантия доставки и большая надежность. Хотя надежность нельзя назвать сильной (нет шифрования и есть возможность взлома), но она достаточная и намного больше, чем у UDP. По крайней мере, тут спуфинг не может быть реализован так просто, как в случае с UDP.
^ Опасные связи ТСР

Рассмотрим, как протокол ТСР обеспечивает надежность соединения. Все начинается еще на этапе попытки соединения двух компьютеров.

  1. Клиент, который хочет соединиться с сервером, отправляет SYN- запрос на сервер, указывая номер порта, к которому он хочет присоединиться, и специальное число (чаще всего случайное).

  2. Сервер отвечает своим сегментом SYN, содержащим специальное число сервера. Он также подтверждает приход SYN- пакета от клиента с использованием АСК- ответа, где специальное число, отправленное клиентом увеличено на 1.

  3. Клиент должен подтвердить приход SYN от сервера с использованием АСК- специальное число сервера плюс 1.

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

Надо еще отметить, что приход любого пакета подтверждается АСК- ответом, что обеспечивает гарантию доставки данных.
^ Прикладные протоколы- загадочный NetBIOS

NetBIOS (Network Basic Input System, базовая система сетевого ввода вывода)- это стандартный интерфейс прикладного программирования. А проще говоря, это всего лишь набор API- функций для работы с сетью (хотя весь NetBIOS состоит только из одной функции, но зато какой…). NetBIOS был разработан в 1983 году компанией Sytek Corporation специально для IBM.

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

Если посмотреть на рис 4.1, то можно увидеть, что NetBIOS находится в самом верху схемы. Он расположен на уровнях сеанса, представления и приложения.

NetBIOS только формирует данные для передачи, а физически они могут передаваться только с помощью другого протокола, например TCP/IP, IPX/SPX и т. д. Это значит, что NetBIOS является независимым от транспорта. Если другие варианты протоколов верхнего уровня (только формирующие пакеты, но не передающие) привязаны к определенному транспортному протоколу, который должен передавать сформированные данные, то пакеты NetBIOS может передавать любой другой протокол. Представьте, что вы написали сетевую программу, работающую через NetBIOS. А теперь осознайте, что она будет прекрасно работать как в unix/windows сетях через TCP, так и в Novell- сетях через IPX.

С другой стороны чтобы два компьютера смогли соединиться друг с другом с помощью NetBIOS, необходимо чтобы на обоих стоял хотя бы один общий транспортный протокол. Если один компьютер будет посылать NetBIOS пакеты с помощью TCP, а другой с помощью IPX, то компьютеры друг друга не поймут. Транспорт должен быть одинаковый.

Стоит сразу же отметить, что не все варианты транспортных протоколов по умолчанию могут передавать по сети пакеты NetBIOS. Например, IPX/SPX сам по себе этого не умеет. Чтобы его обучить, нужно иметь “NWLink IPX/SPX/ NetBIOS Compatible Transport Protocol”. Так как NetBIOS чаще всего использует в качестве транспорта протокол TCP, который работает с установкой виртуального соединения между клиентом и сервером, то по этому протоколу можно предавать достаточно важные данные. Целостность и надежность передачи будет осуществлять TCP/IP, а NetBIOS дает только удобную среду для работы с пакетами и программирования сетевых приложений. Так, что если нужно отправить в сеть какие- либо файлы, то можно смело положиться на NetBIOS.

NetBEUI

В 1985 году уже сама IBM сделала попытку превратить NetBIOS в полноценный протокол, который умеет не только формировать данные для передачи, но и физически передавать их по сети. Для этого был разработан NetBEUI (NetBIOS Extended User Interface, расширенный пользовательский интерфейс NetBIOS), который был предназначен именно для описания физической части передачи данных протокола NetBIOS.

Сразу отметим, что NetBEUI является не машрутизируемым протоколом. Это значит, что если между двумя компьютерами стоит машрутизатор и нет другого пути для связи, то им не удастся установить соединение через NetBEUI.
^ Сокеты Windows

Сокеты (Sockets)- всего лишь программный интерфейс, который облегчает взаимодействие между различными приложениями. Современные сокеты родились из программного сетевого интерфейса, реализованного в OC BSD Unix. Тогда этот интерфейс создавался для облегчения работы с TCP/IP, на верхнем уровне.

С помощью сокетов легко реализовать большинство известных вам протоколов, которые используются каждый день при выходе в Интернет. Достаточно только назвать HTTP, FTP, POP3, SMTP и т. д. Все они используют для отпрвки своих данных или TCP, или UDP и легко программируются с помощью библиотеки sockets/winsock.
^ Протокол IPX/SPX

Осталось только рассказать еще о нескольких протоколах, которые встречаются в повседневной жизни чуть реже, но зато они не менее полезны. Первый и последний на очереди- это IPX/SPX.

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

SPX (Sequence Packet Exchenge)- это транспорт для IPX, который работает с установлением связи и обеспечивает целостность данных. Так что если требуется надежность при использовании IPX, то используйте связку IPX/SPX или IPX/SPX11.

Программирование в Delphi глазами хакера- Спб, 2004-368 с.

Начнем с законов, которые работают не только в программировании, но и в реальной жизни. На последок оставлю только то, что может пригодиться при оптимизации кода.
Закон №1

^ Оптимизировать можно все. Даже там, где вам кажется, что все и так работает быстро, можно сделать еще быстрее.

Это действительно так. И этот закон очень сильно проявляется в программировании. Идеального кода не существует. Даже простую операцию сложения 2+2 тоже можно оптимизировать. Чтобы достичь максимального результат, нужно действовать последовательно и желательно в том порядке, в котором описано ниже.

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

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

Где- то в 1995 году меня посетила одна невероятная идея- написать собственную игру в стиле Doom. Я не собирался делать ее коммерческой, а хотел только про тренировать свои мозги на сообразительность. Четыре месяца невероятного труда, и нечто похожее на движок уже было готово. Я создал один голый уровень, по которому можно было перемещаться, и с чувством гордости побежал по коридорам.

Никаких монстров, дверей и атрибутики на нем небыло, а тормоза ощущались достаточно значительные. Тут я представил себе, что будет, если добавить монстров и атрибуты, да еще и наделить все это AI… Вот тут чувство собственного достоинства поникло. Кому нужен движок, который при разрешении 320x200 в голом виде тормозит со страшной силой.

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

Результат- мир стал прорисовываться на 10% быстрей, но тормозить не перестал. И тут я увидел самое слабое место- вывод на экран. Мой движок просчитывал сцены достаточно быстро, а пробоиной был именно вывод изображения. Тогда еще не было шины AGP, и я использовал простую PCI- видеокарту от S3 с 1 Мбайтом памяти. Пара часов колдовства, и я выжал из PCI все возможное. Откомпилировав движок, я снова загрузился в свой виртуальный мир. Одно нажатие клавиши «вперед», и я очутился у противоположной стены. Никаких тормозов, сумасшедшая скорость просчета и моментальный вывод на экран.

Как видите, моя ошибка была в том, что в начале я неправильно определил слабое место своего движка. Я месяц потратил на оптимизацию математики, и что в результате? Мизерные 10% прироста в производительности. Но когда я реально нашел слабое звено, то смог повысить производительность в несколько раз.

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

Меня поражают люди, которые гонятся за мегагерцами процессора и сидят на доисторической видеокарте от S3, жестком диске на 5400 оборотов и с 32 Мбайтами памяти. Посмотрите в корпус своего компьютера и оцените его содержимое.

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

Тоже самое с видеоадаптером. Если видеокарта у вас слабенькая, то процессор будет просчитывать сцены быстрей, чем они будут выводиться на экран. А это грозит простоями и минимальным приростом производительности.
Закон № 3

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

Опять начнем рассмотрение этого закона с программирования. Допустим, что у вас следующий код (приведена просто логика, а не реальная программа):

  1. А:=А*2;

  2. Б:=1;

  3. Х:=Х+М[Б];

  4. Б:=Б+1;

  5. Если Б<100 то перейти на шаг 3.

Любой программист скажет, что здесь слабым местом является первая строка, потому что там используется умножение. Это действительно так. Умножение всегда выполняется дольше, и если заменить его на сложение (А:=А+А) или еще лучше на сдвиг, то вы выиграете пару тактов процессорного времени. Но только пару тактов, и для процессора это будет незаметно.

Теперь посмотри еще раз на наш код. Больше ничего не видишь? А я вижу. В этом коде используется цикл: «Пока Б<100, будет выполняться операция Х:=Х+М[Б]». Это значит, что процессору придется выполнить 100 переходов с шага 5 на шаг 3. А это уже не мало. Как можно здесь что- то оптимизировать? Здесь у вас внутри цикла выполняется две строки: 3 и 4. Мы внутри цикла размножим их 2 раза.

  1. Б:=1;

  2. Х:=Х+М[Б];

  3. Б:=Б+1;

  4. Х:=Х+М[Б];

  5. Б:=Б+1;

  6. Если Б<50 то перейти на шаг 3;

Здесь цикл разложен на более маленький. Вторую и третью операцию я повторил два раза. Это значит, что за один проход цикла я выполню два раза строки 3 и 4, и только после этого перейти на строку 3, чтобы повторить операцию. Такой цикл нужно повторить только 50 раз (потому что за один раз выполняется два действия). Это значит, что сэкономили 50 операций переходов.

А если внутри цикла написать строки 2 и 3 десять раз? Это значит, что за один проход цикла строки 2 и 3 будут вычисляться 10 раз, и понадобится повторить такой цикл только 10 раз, чтобы получить в результате 100. А это уже экономия 90 операций переходов.

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

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

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

А теперь другой пример- вам на 1 час досталась карточка какого- то нового провайдера. Заносить ее в программу дозвона не имеет смысла, потому что вы можете больше никогда не позвонить ему. Из-за этой одноразовой операции вам придется перенастраивать свой дозвонщик на нового провайдера и потом обратно, а выигрыш практически нулевой, потому что пока вы меняете настройки, уже можно было дозвониться стандартными средствами Windows. Отсюда сразу же напрашивается вывод- нужно правильно выбирать средства для выполнения необходимых задач.
Закон №4

(^ Этот закон- расширение предыдущего)

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

Полгода назад я прочитал рассказ в Интернете «Записки жены программиста» (http://www.exler.ru/novels/wife.htm). Когда я его читал, у меня было ощущение, что его написала моя жена. Там была такая ситуация.

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

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

Получается, что одноразовые операции оптимизировать просто бессмысленно. Затраты в этом случае себя не окупят, поэтому не стоит тратить свои на этот бессмысленный труд.

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

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

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

  1. Старайтесь поменьше использовать вычисления с плавающей запятой. Любые операции с целыми числами выполняются в несколько раз быстрее.

  2. Операции умножения и тем более деления также выполняются достаточно долго. Если вам нужно умножить какое- то число на 3, то для процессора будет легче три раза сложить одно и то же число, чем выполнить умножение.

А как же тогда экономить на делении? Вот тут нужно знать математику. У процессора есть такая операция, как сдвиг. Вы должны знать, что процессор думает в двоичной системе, и числа в компьютере хранятся именно в ней. Например, число 198 для процессора будет выглядеть как 11000110. Теперь посмотрим, как работают операции сдвига.

Сдвиг вправо- если сдвинуть число 11000110 вправо на одну позицию, то последняя цифра исчезнет, и останется только 1100011. Теперь введите это число в калькулятор и переведите его в десятичную систему. Ваш результат должен быть 99. Как видите- это ровно половина числа 198.

Вывод: когда вы сдвигаете число вправо на одну позицию, то вы делите его на 2.

Сдвиг влево- возьмем тоже самое число 11000110. Если сдвинуть его влево на одну позицию, то с правой стороны освободится место, которое заполняется нулем- 110001100. Теперь переведите это число в десятичную систему. Должно получится 396. Что оно вам напоминает? Это 198, умноженное на 2.

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

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

Тут уже нужно сказать, что вы должны действовать аккуратно и с самими параметрами. Не вздумайте пересылать процедурам переменные, которые могут содержать данные большого объема в чистом виде. Лучше передать адрес ячейки памяти, где хранятся данные, а внутри процедуры работать с этим адресом. Представьте ситуацию, когда вам нужно передать текст размером в один том «Войны и мира»…. Перед входом в процедуру программа попытается вогнать все это в стек. Если вы не увидите его переполнения, то задержка точно будет значительная.

  1. В самых критичных моментах (как, например, вывод на экран) можно воспользоваться языком Assembler. Даже встроенный в Delphi или С++ ассемблер намного быстрее штатных функций языка. Ну а если скорость в каком- то месте уж слишком критична, то код ассемблера можно вынести в отдельный модуль. Там его нужно откомпилировать с помощью компиляторов TASM или MASM и подключить к своей программе.

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

^ Для сложных расчетов можно заготовить таблицы с заранее рассчитанными результатами и потом использовать эти таблицы в реальном режиме времени.

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

Как же тогда программистам игры Doom удалось создать трехмерный мир? Секрет прост, как и все в этом мире. Игра не просчитывала сцены, все сложные математические расчеты были рассчитаны заранее и занесены в отдельную базу, которая запускалась при старте программы. Конечно же занести все возможные результаты невозможно, поэтому база хранила основные результаты. Когда нужно было получить расчет значения, которого не было в заранее рассчитанной таблице, то бралось наиболее приближенное число. Таким образом, Doom получил отличную производительность и достаточное качество 3D- картинки.

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

Через некоторое время игровая индустрия поразилась еще больше. Когда вышел Quake3, в котором освещение рассчитывалось в реальном времени, то его мир оказался немного неестественным и даже Half-Life, который вышел позже и на движке старого Quake, выглядел намного естественнее и привычнее. Это получилось в результате того, что мощности компьютера не хватило для полных расчетов в реальном времени, а округления и погрешности пошли не на пользу игровому окружению.
Закон №7

^ Лишних проверок не бывает.

Чаще всего оптимизация может привести к нестабильности исполняемого кода, потому что для увеличения производительности некоторые убирают ненужные на первый взгляд проверки. Запомните, что не нужных проверок не бывает! Если вы думаете, что какая- то нестандартная ситуация может и не возникнуть, то она не возникнет только у вас. У пользователя, который будет использовать вашу программу, может возникнуть все, что угодно. Он обязательно нажмет на то, на что не нужно, или введет неправильные данные.

Обязательно делайте проверки всего того, что вводит пользователь. Делайте это сразу же и не ждите, когда введенные данные понадобятся.

Не делайте проверки в цикле, а выносите за его пределы. Любые лишние операторы if внутри цикла влияют на производительность, поэтому по возможности проверки нужно делать до или после цикла.

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

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


^ Тема 5 Программирование сетевых приложений на низком уровне

Использование функции WINDOWS библиотеки WinSock. Основные функции WinSock: инициализация и соединение. Подключение заголовочных файлов. Получение информации о сокетах. Работа с адресами. Получение информации о сетевом устройстве. Работа с NetBios. Определение локального/ удаленного IP адреса. Добавление и удаление ARP-записей. Работа с сетевыми ресурсами. Частота и загрузка процессора. Получение информации об устройстве вывода: монитора. Работа с типами файлов. Работа со сканером.
^ Объектно- ориентированное программирование
Основные теоретические положения

Считается, что технология процедурного программирования применима, если размер программы не превышает 100 тыс. операторов. Программы, используемые в настоящее время, существенно длиннее. Поэтому современное программирование в основном базируется на технологии, позволившей снять это ограничение и получившей название «объектно- ориентированное программирование» (ООП). Именно ООП лежит в основе таких современных сред создания программного обеспечения «под Windows», как Delphi, Visual C++, C++ Builder.

Определение 1. В теории программирования ООП определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств [2].

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

Объектная декомпозиция

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

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

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

Параметры состояния и элементы поведения объектов определяются условием задачи.

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

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

Пример. Разработать программу исследования элементарных функций, которая для функций y=sin x, y=cos x, y= tg x, y= ln x, y=ex выполняет следующие действия:

  • Строит таблицу значений функции на заданном отрезке с заданным шагом;

  • Определяет корни функции на заданном отрезке;

  • Определяет максимум и минимум функции на заданном отрезке.

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



Похожие рефераты:

Аннотация к электронному пособию «Компьютерные сетевые технологии»
Электронное пособие «Компьютерные сетевые технологии» предназначено для теоретических занятий по теме «Сетевые технологии обработки...
Программа дисциплины «Программирование в среде 1С» для преподавателя...
«Программирование в ср еде 1С» для специальности 5B070400-Вычислительная техника и программное обеспечение
Темы для обязательной контрольной работы По дисциплине «Сетевые технологии в телекоммуникациях»
Описать функции уровней модели osi: канальный, транспортный, сетевой, сеансовый, уровень представления данных и уровень приложения....
Акционерное общество «Мангистаумунайгаз» Протокол об итогах открытого...
«Многофункциональные устройства», №385. 5 «Копировально-множительная техника», №385. 6 «Сервера», №385. 7 «Принтеры», №385. 8 «Измерительный...
Программа вступительного экзамена по специальности 05. 13. 18 Математическое...
«Объектно-ориентированное программирование», «Вычислительные системы и сети», «Системное программирование», «Операционные системы...
Решение №3-15 об утверждении итогов закупки товаров «Переносные накопители,...
«Переносные накопители, дополнительное сетевое оборудование для компьютеров и оргтехники, расходные материалы» способом запроса ценовых...
«Системное программирование»
Контрольная работа по дисциплине «Системное программирование» для студентов 3 курса заочного факультета специальности i-53 01 02...
Рабочая программа дисциплины “Визуальное программирование
«Визуальное программирование» для специальности 5В070200-Автоматизация и управление
Переустановка системы + программы первой необходимости (Microsoft...

Учебно-методический комплекс дисциплины «Визуальное программирование»
Учебно-методические материалыпо дисциплине “ Визуальное программирование ” для студентов

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
referatdb.ru
referatdb.ru
Рефераты ДатаБаза