Можно определить, что адрес является широковещательным?

← →
It's not me (2009-03-04 19:32) [0]

Насколько я понимаю, для удаленной сети невозможно определить является ли определенный адрес широковещательным или нет?

Ну допустим: 83.33.45.200 - это может быть как адресом конкретного хоста, так и широковещательным адресом подсети 83.33.45.*, правильно?

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

Таким образом в случае широковещательного запроса проверку проводить не нужно, например я послал на 192.168.0.255, ответ вернулся с 192.168.0.112. Понятное дело, что в данном случае адрес по которому посылаю не равен адресу от которого пришел ответ.

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

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

Можно ли эту проблему разрешить иным способом, кроме как вводить галочку в настройках непосредтвенно "Указанный IP является широковещательным"?

← →
Anatoly Podgoretsky © (2009-03-04 20:22) [1]

> It"s not me (04.03.2009 19:32:00) [0]

Не может

← →
It's not me (2009-03-05 11:48) [2]

то есть, только галочка? ((

← →
sniknik © (2009-03-05 11:56) [3]

> то есть, только галочка? ((
имхо, лучше определить тип запроса и вставлять его в пакет. т.к. вполне возможны ситуации когда нужны ответы и в ответ на широковещательный, и не нужен когда адресный...

а так сделал 2 типа (пока, может после и больше понадобиться) 1 - слать ответ, 2 - не слать. ну и в клиенте даже не пытаться отвечать при 2-ке... заодно и трафик сэкономишь.

← →
YurikGL © (2009-03-08 08:28) [4]

Я бы исходил из целесообразности. Т.е. если у тебя адресатами запросов являются сети с маской 255.255.255.0, то достаточно проверять последний байт ip-адреса. Если 255.255.0.0, то последние два бита.

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

← →
sniknik © (2009-03-08 23:22) [5]

YurikGL © (08.03.09 08:28) [4]
> Я бы исходил из целесообразности. Т.е. если у тебя адресатами запросов являются сети с маской 255.255.255.0,
> то достаточно проверять последний байт ip-адреса. Если 255.255.0.0, то последние два бита.
когда получаешь пакет то там в ip источника будет не маска, а конкретный адрес... в вопросе про это написано.
что делать с этим с точки зрения целесообразности?

> это знает только компьютер-получатель пакета, в зависимости от того, какое сочетание ip-адреса и маски подсети у него установлено.
это каким таким образом по установленному у получателя, можно знать как что-то посылалось (т.е. настройку "отсылателя")? бред какой то.

← →
korneley © (2009-03-08 23:43) [6]

> sniknik © (08.03.09 23:22) [5]

Понятно, что не два бита, а байта :) Как проверить широковещание? Единицы во всех незамаскированных битах.

← →
Anatoly Podgoretsky © (2009-03-09 00:51) [7]

> korneley (08.03.2009 23:43:06) [6]

Не то и ни другое, а от двух бит до 32 бит и в процессе должны участвовать две согласованые стороны - клиент и сервер(ы)

← →
sniknik © (2009-03-09 01:01) [8]

> Понятно, что не два бита, а байта :) Как проверить широковещание? Единицы во всех незамаскированных битах.
мне не понятно. объясни "на пальцах", а лучше ответь на вопрос автора ветки, повторю его "попроще" (а то видимо "не доходит")
вот ты получил в UDPServer пакет, у него в PeerIP адрес источника = 83.33.45.200, как по этому узнать (или по + настройки машины получателя. рецепт от YurikGL) способ каким этот пакет отправляли так UDPClient.Send("83.33.45.200", "****") или так UDPClient.Send("83.33.45.255", "****").
(т.е. хотя 2 вариант широковещательный, на сервере ты все одно будешь иметь адрес машины посылателя. и где взять "Единицы во всех незамаскированных битах"? хотя чего их брать? нужны не они, а "сырые" данные как посылалось, если бы были то вопроса вообще бы не было, просто смотришь на 255 в конце и понятно что это широковещательный)

← →
Pavia © (2009-03-09 02:31) [9]

Всем читать основы сетей. IP UDP ARP.
Широковещательные пакеты бывают как по IP так и по MAC согласно RFC определены определенные адреса.

Еще не забываем, что уже во всю шагает по планете IPv6. А многии даже не зают как в нем IP адрес выглядит и сколько в нем байт.

← →
korneley © (2009-03-09 06:57) [10]

> sniknik © (09.03.09 01:01) [8]

Опочки! Действительно, я со стороны "посылателя" взглянул :) А у "получателя" все равно будет конкретный автор пакета. Ну так и что? Какая разница кому он (посылатель) ещё пакеты запуздыривает? Мы-то получаем от него, что и видим в PeerIP.

← →
Anatoly Podgoretsky © (2009-03-09 07:45) [11]

Ответ был дан в [1]

← →
sniknik © (2009-03-09 11:23) [12]

> Pavia © (09.03.09 02:31) [9]
прям тащусь с вашей "крутизны", простой в общем то вопрос, нормально заданный, и так "увести в сторону", сказать что то вообще не связанное, послать всех читать основы, хотя на самом деле, сам нечего не понимаешь (вопрос точно не понял)....
браво! брависсимо!!!

korneley © (09.03.09 06:57) [10]
> Ну так и что? Какая разница кому он (посылатель) ещё пакеты запуздыривает?
как что? вопрос об этом. - можно ли ли построить на этом логику программы или придется вставлять разграничитель в посылаемые данные.

Anatoly Podgoretsky © (09.03.09 07:45) [11]
> Ответ был дан в [1]
да, но мы(/я) то уже не об этом... тут товарищи уже какую то целесообразность, "основы сетей" привлекают... не обращая внимание на то что не имеется технической возможности (основы основ)...
я вот уже "за справедливость", не допустить при полной ясности в начале, с нормально заданным вопросом, чтобы кто то в конце оставил мутный коментарий в конце с подтекстом "а все таки можно, но вы ничего не знаете. я знаю но не скажу, читайте основы".
знает так пусть скажет, без запутываний.

← →
YurikGL © (2009-03-09 20:42) [13]

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

> YurikGL © (08.03.09 08:28) [4]
> > Я бы исходил из целесообразности. Т.е. если у тебя адресатами
> запросов являются сети с маской 255.255.255.0,
> > то достаточно проверять последний байт ip-адреса. Если
> 255.255.0.0, то последние два бита.
> когда получаешь пакет то там в ip источника будет не маска,
> а конкретный адрес... в вопросе про это написано.
> что делать с этим с точки зрения целесообразности?
Получатель смотрит ip-адрес получателя (который указан в ip-пакете в поле destination), и сравнивает со своей маской подсети (которая выводится у получателя по ipconfig). В зависимости от того, что получилось по "или" либо считает пакет широковещательным, либо нет.

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

з.ы. собственно, ответ [1] верен. Однако, если заранее известно с какими сетями идет работа, то с большой долей вероятности можно определить, сочтет тот или иной получатель пакет с такими-то параметрами широковещательным или нет.

← →
KilkennyCat © (2009-03-09 20:52) [14]

> уже во всю шагает по планете IPv6

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

← →
It's not me (2009-03-09 20:52) [15]

YurikGL © (09.03.09 20:42) [13]
С точки зрения отправителя, строго говоря, не бывает широковещательных адресов или не_широковещательных адресов. Каждый хост-получатель сам определяет является данных пакет широковещательным или нет
мне всегда нравилось, когда собственные теории выдают с уверенностью фактов.

Если так в твоей теории все стройно и просто, чем же ты объяснишь: http://msdn.microsoft.com/en-us/library/cc526911.aspx а?

← →
Anatoly Podgoretsky © (2009-03-09 21:06) [16]

> It"s not me (09.03.2009 20:52:15) [15]

И что, разве это как то относится к вопросу?

← →
Anatoly Podgoretsky © (2009-03-09 21:07) [17]

> YurikGL (09.03.2009 20:42:13) [13]

И я с такой ситуацией сталкивался, именно так - два хоста в одной сети, а адреса разные.

← →
YurikGL © (2009-03-09 21:14) [18]

> It"s not me (09.03.09 20:52) [15]
> мне всегда нравилось, когда собственные теории выдают с
> уверенностью фактов.

Поставь три виртуальные машины. Соедини их в одну сеть. Установи ip-ки
1) 192.168.0.1 255.255.255.0
2) 192.168.0.2 255.255.0.0
3) 192.168.0.3 255.255.255.0

И попробуй с третьей пропингуй 192.168.0.255. Первая должна отозваться, а вторая - нет.

з.ы. это если я поздно вечером ничего не попутал.

← →
It's not me (2009-03-09 21:19) [19]

YurikGL © (09.03.09 21:14) [18]
И попробуй с третьей пропингуй 192.168.0.255

а что, IMGP поддерживает broadcast?

И вообще, к чему ты сейчас вообще это сказал?

Ты сазал фразу, вот она:

>С точки зрения отправителя, строго говоря, не бывает >широковещательных адресов или не_широковещательных адресов

если эта данная ТВОЯ фраза верная, то как ты объяснишь наличие опции so_broadcast у сокетов. Нафиг ее выставлять и почему она вообще существует, если с точки зрения отправителя НЕ БЫВАЕТ широковещательных адресов?
Причем, если эту опцию не выставить - броадкасты проходить не будут.

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

← →
sniknik © (2009-03-09 21:50) [20]

> если заранее известно с какими сетями идет работа, то с большой долей вероятности можно определить,
> сочтет тот или иной получатель пакет с такими-то параметрами широковещательным или нет.
а чего так обтекаемо то? давай вернем изначальную простоту и ясность...
->
итак, получатель получил пакет в котором в отправителях стоит 83.33.45.200 ..
какая должна быть сеть?, чтобы, с какой долей вероятности?, сказать отправлялось это как 83.33.45.200 или как 83.33.45.255(или вообще как 255.255.255.255)?
только без выкрутасов. так чтобы я со своим рабоче крестьянским мышлением понял.

← →
sniknik © (2009-03-09 21:52) [21]

> это как 83.33.45.200
ну или, как 83.33.45.201 например, что будет вернее.

← →
YurikGL © (2009-03-09 22:02) [22]

> а что, IMGP поддерживает broadcast?

IMPG или IPMG ?

> итак, получатель получил пакет в котором в отправителях
> стоит 83.33.45.200 ..
> какая должна быть сеть?,

см 18.
Если пингуем с третьего компьютера адрес 192.168.0.255, то для первого компьютера приходящий пакет будет широковещательным. Т.к. при сравнении по "или" со своей маской подсети (255.255.255.0) он получит все единицы.
Для второго данный пакет широковещательным являться не будет т.к. при сравнении по "или" он не получит все единицы.

Что же до предположений, то если локалка построена по http://tools.ietf.org/html/rfc1918 то
# 10.0.0.0 — 10.255.255.255 (одна сеть класса A)
# 172.16.0.0 — 172.31.255.255 (шестнадцать сетей класса B)
# 192.168.0.0 — 192.168.255.255 (256 сетей класса C)

← →
YurikGL © (2009-03-09 22:03) [23]

А в интернете широковещательными пакетами лучше вообще не баловаться. Провы этого не любят.

← →
sniknik © (2009-03-09 22:23) [24]

> см 18.
смотрю, и вижу полную чушь.

> Если пингуем с третьего компьютера адрес 192.168.0.255
мы НЕ ПИНГУЕМ (что по броадкастному адресу вообще то не возможно), мы на стороне получателя (исходный вопрос, без увиливаний в стороны), и мы получили пакет(не послали! и не пингуем!), в пакете адрес отправителя. как он его нам отправлял? только нам или "на всех".

> Т.к. при сравнении по "или" со своей маской подсети (255.255.255.0) он получит все единицы.
т.е. от того что установлено в приемнике, зависит как именно посылает источник??? а ка он тогда в такой зависимости вообще может что-то 2мя способами посылать?... а он тем не менее может. в общем, как говорил, тоже бред.

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

← →
YurikGL © (2009-03-09 22:31) [25]

> мы НЕ ПИНГУЕМ (что по броадкастному адресу вообще то не
> возможно), мы на стороне получателя (исходный вопрос, без
> увиливаний в стороны), и мы получили пакет(не послали! и
> не пингуем!), в пакете адрес отправителя. как он его нам
> отправлял? только нам или "на всех".

Ээээ.... набираем в командной строке ping 192.168.0.255. Пакеты уходят в сеть. Первый компьютер на них отзывается (посылает ответ) т.к. считает, что это - широковещательный запрос, а второй - нет.

Или тебя интересует как 2-й уровень это все разбирает?

> т.е. от того что установлено в приемнике, зависит как именно
> посылает источник???
Пакет и первому и второму компьютеру приходит абсолютно одинаковый (на уровне 3 модели OSI).

> в пакете адрес отправителя. как он его нам отправлял? только
> нам или "на всех".
Как кто отправлял? Компьютер? Он просто заполнил поля пакета и все. И каждый получатель либо счел пакет широковещательным (на уровне L3), либо нет.

← →
YurikGL © (2009-03-09 22:33) [26]

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

з.ы. multicast не рассматриваем.

← →
YurikGL © (2009-03-09 22:43) [27]

> как он его нам отправлял? только нам или "на всех".

Светофор на перекрестке зеленым светом светит только тебе или на всех? Вообще - на всех. Но кому то пофигу - ходит на красный, у кого-то корочка, он ездит на красный, а кто-то - вообще дальтоник... :)

← →
sniknik © (2009-03-09 22:51) [28]

> Пакеты уходят в сеть.
? всегда считал что пинг уровнем ниже чем пакеты. ну во всяком случае не то же самое.

> Или тебя интересует как 2-й уровень это все разбирает?
меня интересует ответ на начальный вопрос (на него конечно уже ответили в [1] но ты чего то там про вероятности говорил). можешь прочесть его в 0, не буду больше повторять.

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

procedure TForm1.IdUDPServer1UDPRead(Sender: TObject; AData: TBytes; ABinding: TIdSocketHandle); begin Memo1.Lines.Add(ABinding.PeerIP + " : "+ PChar(AData)); end;

приписываем все в общем компилим, запускаем на компе с IP 192.168.0.1

на втором компе запускаем другую прогу с
procedure TForm1.Button1Click(Sender: TObject); begin IdUDPClient1.Send("192.168.0.1", 5555, "Test"); IdUDPClient1.Send("192.168.0.255", 5555, "Test"); end;

после нажатия на кнопку, на первом видим
192.168.0.2 : TestÆF
192.168.0.2 : TestÆF

теперь представь что ты не видишь кода которым посылалось. видиш только результат, 2 строчки из мемо, какая из них как послана, какая адресно а какая броадкастом?
не знаю зачем, но ты там в маски упирался, ток вот на обоих компах оно 255.255.255.0.
итак?

> ? всегда считал что пинг уровнем ниже чем пакеты. ну во
> всяком случае не то же самое.

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

> теперь представь что ты не видишь кода которым посылалось.
> видиш только результат, 2 строчки из мемо, какая из них
> как послана, какая адресно а какая броадкастом?

Никак не узнаешь. Пакеты будут абсолютно идентичны до L2 (при условии, что сам протокол ping-а ничего не добавляет... а этого я точно не знаю).

> не знаю зачем, но ты там в маски упирался, ток вот на обоих
> компах оно 255.255.255.0.

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

> Никак не узнаешь. Пакеты будут абсолютно идентичны до L2
> (при условии, что сам протокол ping-а ничего не добавляет.
> .. а этого я точно не знаю).

Вру... если отглядеть снифером, то во втором случае на L3 будут разные получатели.

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

> на стороне получателя первый компьютер считает, что пришедший пакет - широковещательный. Второй компьютер, считает, что полученный пакет не_широковещательный.
при раскладе из 18, пакет(пакет, а не пинг!) на второй компьютер попросту не пошлется...
хотя, это так к слову. твои знания сетей мы уже выяснили. говорить с тобой не о чем.

> It"s not me (09.03.2009 21:19:19) [19]

Для определения того, что это датаграмма, соединение не требуется.

> при раскладе из 18, пакет(пакет, а не пинг!) на второй компьютер
> попросту не пошлется...

Ты уверен? Если между ними хаб стоять будет? :))
На самом деле, если будет стоять свич, то уровень L2 действительно отсечет отправку пинга на третий компьютер т.к. предварительно будет послан ARP-запрос с целью выяснения mac-в получателей IP-пакета.

> твои знания сетей мы уже выяснили. говорить с тобой не о
> чем.

эээ... какашками кидаетесь... а сами не знаете, что пинги в пакеты пакуюца...

> а сами не знаете, что пинги в пакеты пакуюца...
во первых вопрос не в этом, и на вопрос ты кроме мути ничего не сказал.
во вторых я и не утверждал, что знаю. хотя знаю кое чего.
в третих краем уха я все таки слышал что пинги это не пакеты (udp), у них даже порта на который они отсылаются нет.
в четвертых это твоя очередная попытка увильнуть? отвести глаза от основного вопроса, который ты сказал можно (с долей вероятности) решить. но так и не сказал как.

> в третих краем уха я все таки слышал что пинги это не пакеты
> (udp), у них даже порта на который они отсылаются нет.

Пакеты это - 3-й уровень модели OSI
http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI

UDP - четвертый уровень модели OSI

Пинги, действительно не ходят через UDP, однако, они пакуются в ip-пакеты третьего уровня.

Понятие широковещательный пакет есть во втором уровне модели OSI (когда mac-адрес состоит из всех единиц) и на третьем (когда ip-адрес с маской дают единицы). Автор вопроса (я так понял) спрашивал про разделение на broadcast и unicast на третьем уровне модели OSI

Ответ такой:
1) На стороне получателя нельзя распознать, "как какой" пакет отправил отправитель пакета. Как unicast или как multicast. Помыслы человека, который заставил компьютер отправить данный пакет неизвестны.
2) На стороне получателя можно узнать "как какой" пакет получил получатель. Получил он его в соответствии с тем, что распознал его как unicast или потому что распознал его как multicast (до этого он получил L2 arp-запрос с вопросом, а не ты ли такой-то ip-к, сравнил запрашиваемый ip-к со своим, потом со своей маской подсети и ответил да, либо не ответил, потом отравитель, получив все ответы отправил пакет L3 с полученными mac-ми. это правильно для сети не разделенной шлюзами). Для этого нужно вытащить с пакета ip-к получателя и сравнить с собственной маской подсети.

← →
It's not me (2009-03-09 23:31) [36]

sniknik © (09.03.09 23:16) [34]
a o?aoeo e?aai ooa y ana oaee neuoae ?oi ieiae yoi ia iaeaou (udp),

iao, eiia?ii. Yoi i?ioieie ICMP, ii ?aaioaao iiaa?o IP n?aco, ia eieainoee?oaony a TCP/UDP.

to [b]YurikGL[/b], ou oae e ia ioaaoee ia i?inoaeoee caaaiiue oaaa aii?in. Anee eae ou aiai?eou ii?aaaeeou oe?ieiaauaoaeuiue aa?an yoi eee iao ii?ii oieuei ia noi?iia iieo?aaony, oi ca eaeei oeaii o nieaoia anou oeaa so_broadcast?

← →
It's not me (2009-03-09 23:34) [37]

вот же блин )

to [b]YurikGL[/b], ты не ответил на элементарнейший вопрос. Если:

>На стороне получателя нельзя распознать, "как какой" пакет отправил
>отправитель пакета

то нафига у сокетов существует опция so_broadcast? Может, подумаешь и поймешь?

> то нафига у сокетов существует опция so_broadcast? Может,
> подумаешь и поймешь?

Я откуда знаю? Может он запрещает прием широковещательных (с точки зрения получателя, а не отправителя) пакетов L3... Может, запрещает отправку. Может, UDP на своем уровне, имеет отдельный свой флажочек "broadcast" не "broadcast". Мне лень разбираться с конкретным параметром :)
Поэкспериментируй - поймешь.

В общем случае (не_UDP) 35 верно.

> В общем случае (не_UDP) 35 верно.
>

В общем случае (не_только_UDP) 35 верно.

← →
It's not me (2009-03-10 01:59) [40]

YurikGL © (09.03.09 23:40) [38]
Может, UDP на своем уровне, имеет отдельный свой флажочек "broadcast" не "broadcast".

может быть

YurikGL © (09.03.09 23:40) [38]
Мне лень разбираться с конкретным параметром :)

ну-ну. А тем не менее этот "конкретный параметр" полностью опровергает твои утверждения:

YurikGL © (09.03.09 23:24) [35]
На стороне получателя нельзя распознать, "как какой" пакет отправил отправитель пакета. Как unicast или как multicast

YurikGL © (09.03.09 22:59) [29]
Потому что не зная маски посети невозможно узнать, широковещательный пакет или нет.

но как я посмотрю, для тебя это мелочь. Подумаешь, какой-то флажок, какой-то конкретный пример - туфта, главное 7-ми уровневая модель )))

Можно определить, что адрес является широковещательным? Найти похожие ветки