Глубины Indy. 2. Техническая поддержка
 Скачать 1.03 Mb.
|
|
Если узел доступен, то вывод выглядит так: C:\ping localhost Обмен пакетами с xp.host.ru [127.0.0.1] по 32 байт: Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Статистика Ping для 127.0.0.1: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек Если узел не доступен, то вывод выглядит так: C:\>ping 192.168.0.200 Pinging 192.168.0.200 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.0.200: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), 3.18. Программа TraceRoute TCP/IP пакеты не двигаются напрямую от узла к узлу. Пакеты маршрутизируются подобно движению автомобилей от одного дома до другого. Обычно, автомобиль должен двигаться более чем по одной дороге, пока не достигнет точки назначения. TCP/IP пакеты двигаются подобным образом. Каждый раз пакет сменяет «дорогу» от маршрутизатора (node) к маршрутизатору. Получив список маршрутизаторов можно определить список узлов (host), по которым путешествует пакет. Это очень полезно для диагностики, почему тот или другой узел недоступен. Traceroute работает из командной строки, Traceroute показывает список IP маршрутизаторов, через которые проходит трасса до узла назначения и сколько требуется 11 времени на каждый прыжок, до каждого узла. Данное время пригодна для поиска узких мест. Traceroute показывает последний маршрутизатор, который нормально обработал пакет, в случае неудачной передачи. Traceroute используется для дальнейшей диагностики после пинга. Пример вывода работы Traceroute при удачном прохождении: C:\>tracert www.atozedsoftware.com Tracing route to www.atozedsoftware.com [213.239.44.103] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms server.mshome.NET [192.168.0.1] 2 54 ms 54 ms 50 ms 102.111.0.13 3 54 ms 51 ms 53 ms 192.168.0.9 4 55 ms 54 ms 54 ms 192.168.5.2 5 55 ms 232 ms 53 ms 195.14.128.42 6 56 ms 55 ms 54 ms cosmos-e.cytanet.NET [195.14.157.1] 7 239 ms 237 ms 237 ms ds3-6-0-cr02.nyc01.pccwbtn.NET [63.218.9.1] 8 304 ms 304 ms 303 ms ge-4-2-cr02.ldn01.pccwbtn.NET [63.218.12.66] 9 304 ms 307 ms 307 ms linx.uk2net.com [195.66.224.19] 10 309 ms 302 ms 306 ms gw12k-hex.uk2net.com [213.239.57.1] 11 307 ms 306 ms 305 ms pop3 [213.239.44.103] Trace complete. 3.19. LAN LAN это сокращение от Local Area Network. Что именно локальная сеть очень зависит от конкретной топологии сети и может варьироваться. Тем не менее, LAN относится ко всем системам, подключенным к Ethernet повторителям (hubs) и коммутаторам (switches), или в некоторых случаях к Token ring или другим. К LAN не относятся другие LAN, подключенные с помощью мостов или маршрутизаторов. То есть к LAN относятся только те части, до которых сетевой трафик доходит без использования мостов и маршрутизаторов. Можно думать об LAN, как об улицах, с мостами и маршрутизаторами, которые объединяют города скоростными трассами. 3.20. WAN WAN это сокращение от Wide Area Network. WAN означает соединение нескольких LAN совместно, с помощью мостов и маршрутизаторов в одну большую сеть. Используя пример с городом, WAN состоит из множества городов (LAN) соединенных скоростными трассами. Интернет сам по себе классифицируются как WAN. 3.21. IETF IETF (Internet Engineering Task Force) это открытое сообщество, которое продвигает функционирование, стабильность и развитие Интернет. IETF работает подобно Open Source разработке программ. IETF доступен на сайте http://www.ietf.org/. 3.22. RFC 12 RFC это сокращение от Request for Comments. RFC это набор официальных документов от IETF, которые описывают и детализируют протоколы Интернет. Документы RFC идентифицируются их номера, подобными RFC 822. Есть очень много зеркал, которые содержат документы RFC в Интернет. Лучший из них, который имеет поисковую системе находится на сайте http://www.rfc-editor.org/ RFC редактор (web сайт указанный выше) описывает документы RFC как: Серия документов RFC – это набор технических и организационных заметок об Интернет (изначально ARPANET), начиная с 1969 года. Заметки в серии RFC документов дискутируют многие аспекты компьютерных сетей, включая протоколы, процедуры, программы и концепции, как заметки, мнения, а иногда и юмор. 3.23. Кодовые потоки (thread) Кодовые потоки – это метод выполнения программы. Большинство программ имеют только один поток. Тем не менее, дополнительные потоки могут быть созданы для выполнения параллельных вычислений. На системах с несколькими CPU, потоки могут выполняться одновременно на разных CPU, для более быстрого выполнения. На системах с одним CPU, множество потоков могут выполняться с помощью вытесняющей многозадачности. При вытесняющей многозадачности, каждому потоку выделяется небольшой квант времени. Так что, кажется, что каждый поток выполняется на отдельном процессоре. 3.24. Fork Unix до сих пор не имеет поддержки потоков. Вместо этого, Unix использует ветвление (forking). С потоками, каждая отдельная строка выполнения исполняется, но она существует в том же самом процессе, как и другие потоки и в том же адресном пространстве. При разветвлении каждый процесс должен сам себя разделять. Создается новый процесс и все хендлы (handles) передаются ему. Разветвление не так эффективно как потоки, но также имеется и преимущества. Разветвление более стабильно. В большинстве случаев - разветвление легче программировать. Разветвление типично для Unix, так как ядро использует и поддерживает его, в то время как потоки это более новое. 3.25. Winsock Winsock – это сокращение от Windows Sockets. Winsock – это определенное и документированное стандартное API, для программирования сетевых протоколов. В основном используется для программирования 13 TCP/IP, но может быть использовано и для программирования Novell (IPX/SPX) и других сетевых протоколов. Winsock реализован как набор DLL и является частью Win32. 3.26. Стек протоколов Термин стек протоколов относится к слою операционной системы, которая сеть и предоставляет API для разработчика по доступу к сети. В Windows стек протоколов реализован с помощью Winsock. 3.27. Сетевой порядок байт Различные компьютерные системы хранят числовые данные в различном порядке. Некоторые компьютеры хранят числа, начиная с самого наименее значимого байта (LSB), тогда как другие с наиболее значимого байта (MSB). В случае сети, не всегда известно, какой компьютер используется на другой стороне. Для решения этой проблемы был принят стандартный порядок байт для записи и передачи по сети, названый сетевой порядок байт. Сетевой порядок байт это фиксированный порядок байт, который должен использоваться в приложении при передаче двоичных чисел 4. Введение в Indy 4.1. Путь Indy Indy разработан изначально на использование потоков. Построение серверов и клиентов в Indy подобно построению серверов и клиентов в Unix, исключая, что это много проще, поскольку у вас есть Indy и Delphi. Приложения в Unix обычно вызывают стек напрямую с минимальным уровнем абстракции или вообще без него. Обычно сервера в Unix имеют один или несколько слушающих процессов, которые наблюдают за пользовательскими запросами. Для каждого клиента, которого требуется обслужить, создается разветвление (fork) процесса. Это делает программирование очень простым, так как каждый процесс обслуживает только одного клиента. Процесс так запускается в собственном контексте безопасности, который может быть установлен на основе слушателя, правах, аутентификации или других предпосылках. Сервера Indy работают подобным образом. Windows в отличии от Unix, не делает разветвление, а создает новый поток. Сервера Indy создают новый поток для каждого клиентского соединения. Сервера Indy создают слушающий поток, который изолирован от главного кодового потока программы. Слушающий поток случает входящие клиентские запросы. Для каждого клиента, которому отвечают, создается новый поток для его обслуживания. Необходимые события возбуждаются в контексте данного потока. 4.2. Методология Indy Indy отличается от других сокетных компонент, с которыми вы возможно уже знакомы. Если вы никогда не работали с другими сокетными компонентами, возможно, вы найдете, что Indy очень прост, так как Indy работает так как вы ожидали. Если вы уже работали с другими сокетными компонентами, то просто забудьте все, что вы знали. Это будет вам только мешать и вы будете делать ложные предпосылки. 14 Почти все другие компоненты работают в неблокирующем режиме, асинхронно. Они требуют от вас реагировать на события, создавать машину состояний и часто исполнять циклы ожидания. Например, с другими компонентами, когда вы делаете соединения, то вы должны ожидать событие соединения или крутить цикл ожидания, пока свойство, ухаживающие факт соединение не будет установлено. С Indy, вы просто вызываете метод Connect и просто ждете возврата из него. Если соединение будет успешное, то будет возврат из метода по окончанию соединения. Если же соединение не произойдет, то будет возбуждено исключение. Работа с Indy аналогична работе с файлами. Indy позволяет поместить весь код в одно место, вместо создания различных разработчиков событий. В дополнение, многие находят Indy более простым в использовании. Indy также разработан на работу с потоками. Если вы имеет проблемы с реализацией чего-либо в Indy, то вернитесь назад и реализуйте это как для файлов. 4.3. Различия Indy Indy использует API блокирующих сокетов. Indy не ориентирован на события. Indy имеет события, но для информационных нужд, но они не обязательны. Indy разработан ни использование кодовых потоков. Тем не менее, Indy может работать без использования потоков. Программирование в Indy – это линейное программирование. Indy имеет высокий уровень абстрагирования. Большинство сокет компонент не очень эффективно изолируют программиста от стека. Большинство сокет компонент вместо изоляции от стека, наоборот погружают его в сложности создания оберток вокруг этого в Delphi / C++ Builder. 4.4. Обзор клиентов Indy разработан для создания высокого уровня абстракции. Сложности и детализация TCP/IP стека скрыты от программиста. Типичный клиент сессия в Indy выглядит так: with IndyClient do begin Host := 'postcodes.atozedsoftware.com' ; // Host to call Port := 6 000; // Port to call the server on Connect; try // Do your communication finally Disconnect; end ; end ; 4.5. Обзор серверов Компоненты серверов Indy создают слушающий поток, который изолирован от главного кодового потока программы. Слушающий поток случает входящие клиентские запросы. Для каждого клиента, которому отвечают, создается новый поток для его обслуживания. Необходимые события возбуждаются в контексте данного потока. 4.6. Потоки 15 Для реализации функциональности используются потоки. Indy очень интенсивно использует потоки для реализации серверов, потоки так же используются и в клиентах. неблокирующие сокеты также могут использовать потоки, но они требуют некоторой дополнительной обработки и их преимущества теряются по сравнению блокирующих сокетов. 5. Блокирующий режим против неблокирующего 5.1. Модели программирования В Windows есть две модели программирования сокетов – блокирующий и неблокирующий. Иногда они также называются как – синхронный (blocking) и асинхронный (non-blocking). В данном документе мы будем использовать термины блокирующий и неблокирующий. На платформе Unix, поддержан только блокирующий режим. 5.2. Другие модели В действительности есть еще несколько реализованных моделей. Это completion ports, and overlapped I/O. Но использование этих моделей требует гораздо больше кода и обычно используется только в очень сложных серверных приложениях. В дополнение, данные модели не кросс платформенные и их реализация сильно отличает от одной операционной системы к другой. Indy 10 содержит поддержку и этих моделей. 5.3. Блокирующий режим В Indy используются вызовы блокирующих сокетов. Блокирующие вызовы очень похожи на чтение/запись файлов. Когда вы читаете файл или пишите файл, то возврат из функции не происходит до ее окончания. Различие состоит в том, что обычно требуется значительно больше времени до окончания. Операции чтения и записи зависят от скорости сети. С Indy, вы просто вызываете метод Connect и просто ждете возврата из него. Если соединение будет успешное, то будет возврат из метода по окончанию соединения. Если же соединение не произойдет, то будет возбуждено исключение. 5.4. Неблокирующий режим Работа неблокирующих сокетов основана на системных событиях. После того как произведен вызов, будет возбуждено событие. Например, для попытки соединения сокета, вы должны вызвать метод Connect. Данный метод немедленно возвращает управление в программу. Когда сокет будет подсоединен, то будет возбуждено событие. Это требует, что бы логика связи была разделена по многим процедурам или использовать циклы опроса. 5.5. История Winsock 16 В начале был Unix. Это был Berkely Unix. Он имел стандартное API для поддержки сокетов. Это API было адоптировано в большинстве Unix систем. Затем появился Windows, и кто-то посчитал, что это хорошая идея иметь возможность программировать TCP/IP и в Windows. Поэтому они портировали API Unix сокетов. Это позволило большинство Unix кода с легкостью портировать и в Windows. 5.6. Блокирующий режим это не смертельно Из-за блокирующего режима мы неоднократно были биты нашими противниками, но блокирующий режим не является дьяволом. Когда API Unix сокетов было портировано в Windows, то ему дали имя Winsock. Это сокращение от "Windows Sockets". В Юниксе типично проблема решалась за счет разветвления (похоже на много поточность, но за счет отдельных процессов вместо потоков). Юникс клиенты и демоны (daemons) должны были раздваивать процессы для каждого сокета. Данные процессы затем выполнялись независимо и использовали блокирующие сокеты. Windows 3.x не мог распараллеливаться и плохо поддерживал многозадачность. Windows 3.1 также не имел поддержки потоков. Использование блокирующих сокетов замораживало пользовательский интерфейс и делало программы не реагирующими. Поскольку это было не приемлемо, то к WinSock были добавлены неблокирующие сокеты, позволяя Windows 3.x с его ограничениями использовать Winsock без замораживания всей системы. Это потребовало другого программирования сокетов, Microsoft и другие страстно поносили блокирующие режимы, что бы скрыть недостатки Windows 3.x. Затем пришли Windows NT и Windows 95, Windows стала поддержать вытесняющую многозадачность и потоки. Но к этому моменту мозги уже были запудрены (то есть разработчики считали блокирующие сокеты порождением дьявола), и уже было тяжело изменить содеянное. По этому поношение блокирующих режимов продолжается. В действительности, блокирующее API единственное которое поддерживает Unix. Некоторые расширения, для поддержки неблокирующих сокетов были добавлены и в Unix. Эти расширения работают совсем не так как в Windows. Эти расширения не стандартны для всех Unix платформ и не используются широко. Блокирующие сокеты в Unix все еще используются в каждом приложении и будут продолжаться использоваться и дальше. Блокирующие сокеты также имеют и другие преимущества. Блокирующие сокеты много лучше для поточности, безопасности и по другим аспектам. 5.7. Достоинства блокирующего режима 1. Проще программировать - Блокирующие сокеты проще программировать. Весь пользовательский код может находиться в одном месте и выполняться в естественном, последовательном порядке. 2. Кросс-платформенность – поскольку Unix использует блокирующие сокеты, по переносимый код легче писать. Indy использует данный факт для использования 17 своего кода между платформами. Другие сокет компоненты, которые кросс платформенные, на самом деле эмулируют это с помощью внутреннего вызова блокирующих сокетов. 3. Удобнее работать с потоками - Поскольку у блокирующих сокетов последовательность приобретена по наследственности, поэтому их очень просто использовать в потоках. 4. Независимость от сообщений – неблокирующие сокеты зависят от системы оконных сообщений. Когда используются потоки, то создается отдельная очередь сообщений. Но когда потоки не используются, то узким местом становится обработка множества соединений. 5.8. Недостатки блокирующего режима 1. Пользовательский интерфейс замораживается в клиентах - Вызов блокирующего сокета не возвращает управления, пока не выполнит свою задачу. Когда подобные вызовы делаются в главном кодовом потоке, то приложение замораживает пользовательский интерфейс. Замораживание происходит, поскольку сообщения обновления, перерисовки и другие сообщения не обрабатываются до окончания вызова блокирующего сокета. 5.9. Компонент TIdAntiFreeze В Indy имеется специальный компонент, который решает проблему замораживания пользовательского интерфейса. Просто добавьте один компонент TIdAntiFreeze куда ни будь в своем приложении, и вы сможете выполнять блокирующие вызовы без замораживания пользовательского интерфейса. Сам компонент будет рассмотрен в подробностях чуть позже. Использование TIdAntiFreeze позволяет получить все преимущества блокирующих сокетов, без видимых недостатков. 5.10. Достоинства неблокирующего режима 1. Пользовательский интерфейс не замораживается – поскольку пользовательский код обрабатывает оконные сообщения, то имеет контроль и над сокетными сообщениями. Поэтому Windows также может обрабатывать и другие сообщения. 2. Многозадачность без использования потоков – используется единственный кодовый поток для обработки множества сокетов. 3. Очень малая нагрузки при множестве сокетов – поскольку множество сокетов могут обрабатываться без потоков, то нагрузка на память и процессор значительно ниже. |