Как послать широковещательный запрос в сеть windows

Обновлено: 04.07.2024

Отсюда вопрос: возможен ли широковещательный запрос по TCP, если именно этот протокол целесообразно использовать в игре, или все равно необходимо использовать UDP для того, чтобы найти партнеров?

При маске 255.255.255.0 широковещательный запрос, понятное дело, х.х.х.255, а если маск 255.255.252.0?

Если комп находится за роутером и посылает широковещательный запрос, проходит ли он через роутер наружу? И если проходит, то по каким адресам рассылается? (например, у вннтренней сети маскак 255.255.255.0, а у внешней - 255.255.252.0)

В подробности не втыкал, точнее не читал, но тема эта :).

Попробуй поставить опции сокета (setsockopt) в SO_BROADCAST. По TCP/IP броадкаст существует, вроде бы.
Но в любом случае такие пакеты как правило редки (только для поиска клиентов), когда ты составишь список игроков, тебе не понадобится рассылать. ИМХО.

TCP - протокол с установлением соединения и подтверждением передачи, поэтому в нем не должно быть широковещательного запроса.

Что мешает использовать для поиска UDP, а далее TCP ?

>Что мешает использовать для поиска UDP, а далее TCP ?

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

Хорошо, остались два других вопроса:

-При маске 255.255.255.0 широковещательный запрос, понятное дело, х.х.х.255, а если маска 255.255.252.0?

-Если комп находится за роутером и посылает широковещательный запрос, проходит ли он через роутер наружу? И если проходит, то по каким адресам рассылается? (например, у вннтренней сети маскак 255.255.255.0, а у внешней - 255.255.252.0)

broadcast обычно через роутеры не проходит. Если было бы иначе, интернет давно бы уж загнулся.

Есть multicast, он ходит через те роутеры, которые о нем знают.

Ну вот конкретная задача: 3 компа находятся в маленькой локальной подсетке с маской 255.255.255.0, находящейся за роутером (конкретно D-Link 604). Роутер подключен к сети с примерно 800 компьютерами, разбитой на несколько сегментов с маской 255.255.252.0. Вопросы:
- попадет ли широковещательный запрос в ближайший сегмент сети за роутером?
- попадет ли широковещательный запрос в другие сегменты?
Что надо сделать для того, чтобы попал?

Существуют же игры без выделенного сервера. Как-то они находят друг друга? Так вот, в какой окрестности они могут найти партнера, разве толко до самого ближайшего роутера?

роутер обрубит все шв пакеты и дальше текущего сегмента они не улетят

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

Нехорошо по broadcast'у вести интенсивный обмен данными. Побить могут, поскольку тем, которые не играют, сеть тоже нужна, а широковещательные рассылки ее замусоривают насмерть.

Альтернативные способы поиска партнеров:
- Ввод ip-адреса сервера вручную.
- Сайт-посредник.

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

>Нехорошо по broadcast'у вести интенсивный обмен данными. Побить могут, поскольку тем, которые не играют, сеть тоже нужна, а широковещательные рассылки ее замусоривают насмерть.
Кто говорит об интенсивном обмене?
Задача единственная - найти партнера по игре. При благоприятном стечении обстоятелств, на один запуск программы - один пакет. При неудачном - пакеты периодически перезапускаются. Например, раз в минуту.

>Альтернативные способы поиска партнеров:
>- Ввод ip-адреса сервера вручную.
>- Сайт-посредник.
Ни один из предложенных методов не устраивает.
Постоянно действующий сервер неприемлем, а откуда простой пользователь может знать IP-адрес компа, владелец которого в то же самое время захотел пограть в ту же самую игру?
Компы сами должны находить друг друга, а не напрягать этим пользователя.

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

Свитчи d-link-а на 16 и 24 портов (модель не скажу, не помню) при довольно интенсивном обмене броадкстом могут интерпритировать его как broadcast storm атаку и просто отключат передачу. Свитч как бы умрёт, пока не прекратиться обвал пакетов. Мультикаст (броадксат для TCP) ВСЕ свитчи 2 уровня пропускают, а вот с апаратами третьего уровня (маршрутизаторы, брандмауеры, управляемые свитчи 3 уровня, например D-link DES 3326 ) надо настраивать, чтобы они мультикаст пропускали.
Большая часть свитчей и ВСЕ хабы пропускают любой броадкаст в любом количестве. Все c-net-ы, мелкие d-link-и (которые по 5 и 8 портов, мелкие тренднеты).
хабы, будучи репиторами вообще ВСЁ пропускают, любой сигнал :)

Краткое содержание:

Для широковещательных пакетов используется последний адрес подсети. Скажем, для подсети 192.168.0.0 с маской 255.255.255.0 широковещательный адрес — 192.168.0.255.

Широковещательный адрес

Пакет, отправленный на этот адрес придёт всем узлам, подключенным к подсети и поддерживающим широковещательные пакеты.

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

Во-первых, определим сам широковещательный адрес для нашей сети:

Теперь можно посылать широковещательный пинг и смотреть как девайс(ы) на него отзываются)

Широковещательный пинг

До этого момента мы прописывали IP-адрес и другие параметры, нужные для работы в сети в явном виде. Что очень неудобно — требуется отдельно конфигурировать каждый девайс перед использованием. Совершенно не годится если ты захочешь, например, подарить кому-нибудь готовый девайс.

DHCP-сервер есть почти во всех сетях. В домашних роутерах он, как правило, включен по умолчанию, etc. То, что нужно!

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

Если DHCP-сервер вдруг перестанет работать, узел может попробовать найти другой DHCP-сервер и запросить у него такой же адрес.

Если срок использования IP-адреса истечёт (и продлить его не удасться), узел возвращается в исходное состояние и пробует снова найти DHCP-сервер и выделить адрес.

DHCP несколько тяжёлый протокол для МК. Но и пользы от него немало. Можно немножко облегчить DHCP — оставить только функцию получения конфигурационных параметров и функцию, повторяющую запрос через определённый интервал.

Формат пакета DHCP:

DHCP-пакет

DHCP является расширенной версией протокола загрузки по сети BOOTP, и формат пакета в общем-то унсаледован от него. Так что почти вся полезная информация лежит в опциях.

DHCP-опция

Между опциями могут вставляться нули для выравнивания опций на 2 байта. После всех опций вставляется байт 0xff — индикатор конца поля.

В общем, всё понятно из кода

В коде встречаются псевдофункции gettc() и rtime() — они возвращают, соответственно количество милисекунд и секунд с момента включения питания. Удобно для отсчёта различных интервалов.

Запросы на выделение адреса отправляются на адрес 255.255.255.255. Пока хост не сконфигурирован (IP-адрес и маска = 0.0.0.0) этот адрес и служит широковещательным.

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

Ещё один момент — по хорошему нам нужно следить за состоянием линка. При втыкании провода нужно обновлять адрес.

Вот пример использования:

Заключение

Заходим на роутер и, обновляя страничку, палим в реальном времени как девайс получает и обновляет адрес по DHCP.

DHCP

Время выделения адреса я для прикола установил в 2 минуты.

Конечно DHCP немного тяжеловат для МК (моя реализация отожрала больше 2 КБ прошивки). Зато избавляет от необходимости настраивать девайс вручную, что тоже довольно ценно.

Итак, про UDP на этом всё.

В следующий раз будет обещаная статья про связь с компом. А потом перейдём к самому интересному)

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

Как известно, адресация в сети Internet представляет собой 32-битовую последовательность 0 и 1, называющихся IP-адресами. Но непосредственно связь между двумя устройствами в сети осуществляется по адресам канального уровня (MAC-адресам).

Так вот, для определения соответствия между логическим адресом сетевого уровня (IP) и физическим адресом устройства (MAC) используется описанный в RFC 826 протокол ARP (Address Resolution Protocol, протокол разрешения адресов).

ARP состоит из двух частей. Первая – определяет физический адрес при посылке пакета, вторая – отвечает на запросы других станций.

Протокол имеет буферную память (ARP-таблицу), в которой хранятся пары адресов (IP-адрес, MAC-адрес) с целью уменьшения количества посылаемых запросов, следовательно, экономии трафика и ресурсов.

Пример ARP-таблицы.

192.168.1.1 08:10:29:00:2F:C3
192.168.1.2 08:30:39:00:2F:C4

Слева – IP-адреса, справа – MAC-адреса.

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

Записи ARP-таблицы бывают двух вид видов: статические и динамические. Статические добавляются самим пользователем, динамические же – создаются и удаляются автоматически. При этом в ARP-таблице всегда хранится широковещательный физический адрес FF:FF:FF:FF:FF:FF (в Linux и Windows).

Создать запись в ARP-таблице просто (через командную строку):

arp –s <IP-адрес> <MAC-адрес>

Вывести записи ARP-таблицы:

После добавления записи в таблицу ей присваивается таймер. При этом, если запись не используется первые 2 минуты, то удаляется, а если используется, то время ее жизни продлевается еще на 2 минуты, при этом максимально – 10 минут для Windows и Linux (FreeBSD – 20 минут, Cisco IOS – 4 часа), после чего производится новый широковещательный ARP-запрос.

  • тип сети (16 бит): для Ethernet – 1;
  • тип протокола (16 бит): h0800 для IP;
  • длина аппаратного адреса (8 бит);
  • длина сетевого адреса (8 бит);
  • тип операции (16 бит): 1 – запрос, 2 — ответ;
  • аппаратный адрес отправителя (переменная длина);
  • сетевой адрес отправителя (переменная длина);
  • аппаратный адрес получателя (переменная длина);
  • сетевой адрес получателя (переменная длина).

А вот как происходит определение маршрута с участием протокола ARP.

Пусть отправитель A и получатель B имеют свои адреса с указанием маски подсети.

  1. Если адреса находятся в одной подсети, то вызывается протокол ARP и определяется физический адрес получателя, после чего IP-пакет инкапсулируется в кадр канального уровня и отправляется по указанному физическому адресу, соответствующему IP-адресу назначения.
  2. Если нет – начинается просмотр таблицы в поисках прямого маршрута.
  3. Если маршрут найден, то вызывается протокол ARP и определяется физический адрес соответствующего маршрутизатора, после чего пакет инкапсулируется в кадр канального уровня и отправляется по указанному физическому адресу.
  4. В противном случае, вызывается протокол ARP и определяется физический адрес маршрутизатора по умолчанию, после чего пакет инкапсулируется в кадр канального уровня и отправляется по указанному физическому адресу.

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

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

Существуют еще протоколы InARP (Inverse ARP), который выполняет обратную функцую: по заданному физическому адресу ищется логический получателя, и RARP (Reverse ARP), который схож с InARP, только он ищет логический адрес отправителя.

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

Клиентом DHCP может быть практически любое сетевое устройство, настроенное на автоматическое получение IP-адреса. Из операционных систем корпорации Microsoft клиентом DHCP могут быть все системы, имеющие стек TCP/IP (вплоть до системы MS-DOS).

Клиенты посылают запрос на аренду IP-адреса при своей первой загрузке, при смене настройки получения IP-адреса со статической на динамическую, а также с помощью команд ipconfig /release (освобождение арендованного IP-адреса) и ipconfig / renew (запрос на новую аренду).

Внимание! Сервер DHCP обязательно должен иметь статические IP-адреса на всех установленных в нем сетевых адаптерах.

Авторы рекомендуют вообще на всех серверах использовать только статические IP-адреса.

Замечание. При отсутствии в сети DHCP-сервера клиенты, настроенные на автоматическую настройку IP-адреса будут самостоятельно назначать себе IP-адреса из подсети класса B — 169.254.0.0/16 . Данная технология называется автоматической IP-адресацией ( APIPA, Automatic Private IP Addressing ) и поддерживается операционными системами Microsoft, начиная с Windows 98.

Агент ретрансляции DHCP-запросов

Как уже говорилось выше, один сервер DHCP может обслуживать клиентов, расположенных в различных IP-сетях. Чтобы широковещательные запросы на аренду IP-адреса достигали DHCP-сервер из любой подсети, необходимо на маршрутизаторах, объединяющих разные IP-сети в единую сеть, установить и настроить агент ретрансляции DHCP ( DHCP Relay Agent ). Пример такой конфигурации изображен на рис. 10.13.

В данном примере изображены две IP-сети класса C — 192.168.0.0/24 и 192.168.1.0/24 . DHCP-сервер (имеющий IP-адрес 192.168.0.121 ) установлен в первой подсети и содержит 2 области — Scope-1 с диапазоном адресов 192.168.0.1–192.168.0.100 и Scope-2 с диапазоном адресов 192.168.1.1–192.168.1.100 . Между двумя подсетями установлен маршрутизатор R, имеющий в первой подсети сетевой интерфейс с IP-адресом 192.168.0.101 , а во второй подсети сетевой интерфейс с IP-адресом 192.168.1.101 . На маршрутизаторе запущен агент ретрансляции DHCP-запросов, настроенный на перенаправление широковещательных DHCP-запросов на сервер с IP-адресом 192.168.0.121 .

Клиенты DHCP, находящиеся в первой подсети, посылают широковещательные запросы на аренду IP-адреса, которые напрямую попадают на DHCP-сервер.

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

Служба WINS

Служба WINS ( Windows Internet Name Service ) выполняет задачи, аналогичные задачам службы DNS, — динамическая регистрация имен компьютеров и других сетевых узлов и их IP-адресов в БД сервера WINS и разрешение имен компьютеров в IP-адреса. Главное отличие в том, что WINS функционирует в совершенно ином пространстве имен, т.н. пространстве имен NetBIOS, которое никак не пересекается с пространством FQDN-имен, в котором работает служба DNS. По этой причине службу WINS еще иначе называют NetBIOS Name Service ( NBNS ). До появления системы Windows 2000 сетевой программный интерфейс NetBIOS был основным сетевым интерфейсом для обмена данными между компьютерами в сетях на базе технологий Microsoft (технология SMB — предоставление совместного доступа к файлам и печати — работала только с помощью сетевого интерфейса NetBIOS), и поэтому служба WINS была основной службой разрешения имен компьютеров в IP-адреса. После выхода Windows 2000 служба файлов и печати может работать без NetBIOS, и основной технологией разрешения имен в IP-адреса стала служба DNS. Если в вашей сети нет операционных систем Windows 95/98/ME/NT, то вам служба WINS может вообще не потребоваться.

Пространство имен NetBIOS

Имена NetBIOS не образуют никакой иерархии в своем пространстве, это простой линейный список имен компьютеров, точнее работающих на компьютере служб. Имена компьютеров состоят из 15 видимых символов плюс 16-й служебный символ. Если видимых символов меньше 15, то оставшиеся символы заполняются нулями (не символ нуля, а байт, состоящий из двоичных нулей). 16-й символ соответствует службе, работающей на компьютере с данным именем.

Просмотреть список имен пространства NetBIOS, которые имеются на данном компьютере, можно с помощью команды " nbtstat –n ".

Имя " ..__MSBROWSE__ ." говорит о том, что данный компьютер является Обозревателем сетевого окружения по протоколу TCP/IP. Т.е. если на каком-либо компьютере с системой Windows открыть " Сетевое окружение ", то данный компьютер будет запрашивать список компьютеров, сгруппированных в сетевой рабочей группе WORLD, именно с сервера DC1.

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

Установка службы WINS

Установка службы WINS выполняется по той же схеме, что и установка службы DHCP: " Пуск " — " Панель управления " — " Установки и удаление программ " — " Установки компонентов Windows " — " Сетевые службы " — кнопка " Состав " — выбрать пункт " WINS " — кнопки " ОК ", " Далее " и " Готово " (если потребуется, то указать путь к дистрибутиву системы).

Настройка клиента WINS

Для настройки сетевых компьютеров для использования ими сервера WINS необходимо в Свойствах протокола TCP/IP на закладке " WINS " указать IP-адреса используемых в сети WINS-серверов (для узлов со статическими IP-адресами; рис. 10.15) или добавить необходимые параметры в свойствах соответствующей области сервера DHCP (для узлов с динамическими IP-адресами).

Клиент после таких изменений сделает попытку автоматической регистрации своих данных на сервере WINS. Автоматическая регистрация клиента на WINS-сервере осуществляется также в процессе загрузки системы на компьютере или командой " nbtstat –RR ".

Для просмотра записей, хранящихся в БД WINS-сервера, необходимо открыть консоль управления WINS, раскрыть в консоли узел, относящийся к данному серверу, щелкнуть правой кнопкой мыши на разделе " Активные регистрации " и выбрать " Отобразить записи " (рис. 10.15):

Читайте также: