Поле узла источника — это адрес MAC узла источника. Адреса широковещания недопустимы.
Сокет источника Сокет источника — это адрес процесса, передающего пакет. Процессам, общающимся при равноправном соединении узлов, не требуется посылать и получать один и тот же номер сокета. В сети рабочих станций и серверов сервер обычно "ожидает" на определенном сокете запросы на обслуживание. В таком случае сокет источника не обязательно тот же самый или вообще имеет значение. Важно только, чтобы сервер ответил сокету источника. Например, все файловые серверы NetWare имеют один и тот же адрес сокета, но запрос к ним может исходить из сокета с любым номером.
Номера сокетов источников следуют тем же соглашениям, что и сокеты места назначения.
Заголовки протоколов более высокого уровня Заголовки протоколов более высокого уровня принадлежат таким Протоколам, как NCP или SPX. Они часто встречаются в части данных пакета IPX.
Адресация IPX
Теперь рассмотрим адресацию IPX. Как показано в таблице 3.3, IPX имеет свою собственную адресацию узлов (для внутрисетевой работы) и внутриуз-ловую адресацию. Для адресации узла IPX использует адрес MAC, который был присвоен карте сетевого интерфейса производителем самой карты.
Сетевой адрес IPX уникальным образом идентифицирует сервер IPX в сети IPX и отдельные процессы внутри сервера. Адрес IPX является 12-байтовым шестнадцатеричным числом, которое можно разделить на три части. Первая часть адреса IPX — самая длинная, это шестибайтовый аппаратный адрес сетевого адаптера. Последняя часть является двухбайтным номером сокета, который используется для ссылки на реальный выполняющийся на машине процесс. В таблице 3.3 показано, как выглядит этот адрес.
Каждый номер в адресе IPX содержится в поле в заголовке IPX и представляет сеть источника или места назначения, узел или сокет. Сетевой номер используется только для операций сетевого уровня, а именно, маршрутизации. Номер узла используется для локальной (или в том же сегменте) передачи пакетов. Номер сокета направляет пакет в процесс, действующий внутри узла.
Каждый адресный компонент описывается в следующих разделах.
Номер узла является шестибайтовым шестнадцатеричным числом, используемым для уникальной идентификации устройства в среде IPX. Это число идентично физическому адресу платы сетевого интерфейса, который соединяет устройство с сетью.
Заголовок IPX содержит поля узла назначения и узла источника. Поскольку номера узлов являются такими же, как адреса сетевой интерфейсной платы, эти поля содержат такие же адреса места назначения и источника, как находящиеся в заголовке MAC. Например, рабочая станция, выполняющая IPX/SPX, использует адрес узла назначения для определения места и пересылки пакетов другой рабочей станции в том же сетевом сегменте.
Номер узла IPX должен быть уникальным в том же сетевом сегменте. Например, узел в сети 3001 может использовать номер 006008A1D4B4, а узел в сети 3002 также может использовать номер 006008A1D4B4. Это действует так же, как протокол IP, потому что адрес хоста может совпадать в различных сетях IP. Поскольку каждый узел имеет отличный сетевой номер, IPX распознает каждый узел, как имеющий законный уникальный адрес.
Номер сокета
Двухбайтовый шестнадцатеричный номер сокета идентифицирует место назначения процесса внутри узла. Это может быть нечто вроде маршрутизации (RIP) или объявления (внутри устройства SAP). Так как обычно одновременно действуют несколько процессов, номер сокета обеспечивает что-то вроде "почтового ящика", используемого каждым процессом для идентификации себя для IPX.
Когда процессу требуется коммуникация в сети, он запрашивает номер сокета. Все пакеты, полученные IPX и адресованные сокету, пересылаются затем процессу. Номера сокетов предоставляют быстрый метод маршрутизации пакетов в узле. Это работает таким же образом, как сокеты Windows или номера портов TCP/IP. Они являются логическими местами назначения на удаленной машине для межпроцессной коммуникации. В таблице 3.5 перечислены некоторые номера сокетов и процессы, встречающиеся обычно в достаточно активных сетях.
Сокеты под номерами между 0x4000 и 0x7FFF являются динамическими; они создаются в ходе работы, когда рабочей станции понадобится коммуникация с файловым сервером или другими сетевыми устройствами. Сокеты под номерами между 0x8000 и OxFFFF являются общеупотребительными; Novell присваивает их определенным процессам. Например, 0x9001 является номером сокета, который идентифицирует NLSP. Разработчики программного обеспечения, пишущие приложения NetWare, могут контактировать с Novell для выяснения общеупотребительных сокетов.
NCP разрешает клиенту общаться с сервером с помощью системы доставки сообщений, например IPX или SPX. SPX имеет преимущество, поддерживая упорядочивание и гарантированную доставку сообщений. Если понадобится, то может запрашиваться IPX, с целью улучшения производительности. Он предлагает преимущество использования низкоуровневого ненадежного интерфейса дейтаграмм, такого как IPX. Кроме того, дейтаграммы предлагают перенос NCP в сети, где стандартные интерфейсы сеанса не существуют.
В настоящее время большинство клиентов ограничены не более чем одним ожидающим запросом NCP для каждого соединения. Однако между двумя компьютерами может существовать несколько соединений. Если клиент пользуется мультипользовательской системой, каждый пользователь может иметь отдельное соединение с сервером, а каждому соединению разрешено иметь ожидающий запрос NCP.
Так как система безопасности доступа к серверу определяется на основе каждого соединения, то для нескольких задач принято использовать общее единственное соединение. При необходимости для каждой задачи могут быть созданы новые соединения в мультизадачной среде. Каждое новое соединение интерпретируется как отдельная сущность, несмотря на физическую машину, которая осуществляет соединение. Таким образом, клиент может поддерживать столько соединений с различными серверами, сколько потребуется.
Структуры заголовка сообщений
Посмотрим теперь на сообщение NСР. Сообщение NСР содержит семи-байтный заголовок запроса, за которым следует восьмибайтный заголовок ответа. Заголовок запроса содержит общую статусную информацию о текущем состоянии соединения и указывает требуемую службу
Получив подходящий IP-адрес, клиентский компьютер должен зарегистрировать в сети свое имя NetBIOS. В большинстве ситуаций эта регистрация будет вовлекать WINS. Большинство ресурсов, доступных в сети, включает некоторый вид компьютерного имени. Компьютеры в сети должны регистрировать по крайней мере одно имя. Как правило они будут регистрировать более одного имени, чтобы обеспечить в сети коммуникацию по имени. В мире Windows NT имя хоста и имя NetBIOS обычно совпадают (они не являются одним и тем же по сути, но обозначаются одним и тем же словом или комбинацией символов). В мире Unix имя хоста и имя NetBIOS могут быть различаться.
В главе 1 говорилось, что NetBIOS (сетевая базовая система ввода-вывода) не то же самое, что NetBEUI. NetBIOS является протоколом, используемым различными приложениями. Он может переноситься через TCP/IP, IPX/SPX и, конечно, NetBEUI. Мы рассмотрим NetBIOS, потому что она используется через TCP/IP.
Чтобы приложения могли общаться, имя NetBIOS должно быть преобразовано в адрес IP. Способ, которым это обычно делается, состоит в испо льзовании либо широковещания b-узлов, либо сервера имен NetBIOS, например WINS. Есть несколько преимуществ использования сервера WINS, а не просто широковещания. Первое состоит в том, что широковещание является очень дорогим предложением, когда речь идет о сетевой производительности. Каждое одиночное устройство в сегменте должно остановить и проверить каждый одиночный кадр широковещания, чтобы определить, не может ли он обслужить запрос. В большой сети широковещание NetBIOS может буквально заполнить всю сеть. С этим надо как-то бороться. К счастью, компания Microsoft разработала для этой цели WINS. WINS полностью соответствует реализации сервера имен NetBIOS на основе RFC. С помощью WINS хосты могут отбрасывать кадр, как только они видят адрес MAC места назначения. Все функции службы имен NetBIOS через TCP/IP используют UDP порт 137. Рассмотрим регистрацию имен и процесс обновления.
Регистрация имен и обновление
Имена NetBIOS должны быть зарегистрированы для каждой службы или приложения, которые хотят использовать их коммуникационный механизм. Примерами таких регистрируемых служб являются служба рабочей станции и служба сервера. Другие имена указывают специальные роли, которые выполняются в сети, такие как основной, или первичный, контроллер домена (Primary Domain Controller, PDC) или резервный контроллер домена (Backup Domain Controller, BDC). Регистрируется само имя домена, а также имена пользователей, регистрирующихся в домене. Эти имена нужны для некоторых функций сообщений и коммуникации. Например, если необходимо послать сообщение, используя сетевую команду send (послать) некому Джейсону, он должен иметь зарегистрированное имя пользователя, иначе ничего не получится. Общее число зарегистрированных имен зависит, очевидно, от числа запущенных служб. Каждое зарегистрированное имя будет использовать всего 214 байтов — 110 байтов для запроса регистрации имени и 104 байта для ответа. Посмотрим теперь на такую транзакцию на листинге ниже:
