[ClockworkOrange 0]

вопрос к знатокам:

а что нужно (какая поддержка в движке), чтобы

1) иметь возможность отправлять сообщения по UDP (посредством Ethernet)

2) иметь возможность отправлять и принимать сообщения по UDP (посредством Ethernet)

 

вопрос родился не не пустом месте, а при изучении талмудов типа:

"Embedded Ethernet and Internet Complete" и

"TCP-IP Lean-Web Servers for Embedded Systems"

ведь помимо самого IP или UDP/TCP существуют такие протоколы как ARP, ICMP - cмущает еще и то ,что в самом теле пакета UDP/IP не содержится МАС-адреса, т.е. мягко говоря не совсем понятно как он будет ходить по сети ((.

[zltigo 2]

вопрос..

UDP + ARP. Для абсолютно минмального по Ethernet все.

..cмущает еще и то ,что в самом теле пакета UDP/IP не содержится МАС-адреса, т.е. мягко говоря не совсем понятно как он будет ходить по сети ((.

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

[ClockworkOrange 0]

UDP + ARP. Для абсолютно минмального по Ethernet все.

 

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

что-то не получается понять до конца((

 

т.е. если точка-точка, то можно напрямую без ARP, а если например через хаб/свич - притом все сидят в одной подсети - тогда?..

 

слать/приниматьcя пакеты UDP будут только к/от конкретного IP

 

в самом протоколе есть типы команд:

#define ARPREQ 0x0001 /* ARP request */
#define ARPRESP 0x0002 /* ARP response */

а кто их рассылает ("мастер"?)?.. как часто?.. поддержка каких запосов требуется??

 

PS: просто для начала хотелось бы почитать что-нить попроще RFC 826. на пальцах понять так сказать

[zltigo 2]

что-то не получается понять до конца((

т.е. если точка-точка

Нет. Ethernet, это уже не точка-точка по определению. Точка-точка это, наппимер, RS232.

в самом протоколе есть типы команд:

ARP запрос посылает (с broadcast MAC) тот, кто не знает MAC адрес назначения для первой посылки.

Отвечает владелец IP адреса, при этом, естественно он уже отвечает со своим MAC.

Связка MAC<->IP попадает в ARP кэш и хранится там некоторое, определенное конфигурацией, время.

[Кнкн 5]

т.е. если точка-точка, то можно напрямую без ARP, а если например через хаб/свич - притом все сидят в одной подсети - тогда?..

слать/приниматьcя пакеты UDP будут только к/от конкретного IP

 

Если MAC-адреса известны с обоих концов, то можно обойтись и без ARP.

[ClockworkOrange 0]

cпасибо за ответы.. немножко уже проясняется..

 

заодно удалось накопать что-то на русском:

http://book.itep.ru/4/44/arp_446.htm

http://www.protocols.ru/files/RFC/rfc826.pdf

 

определены МАС и IP со стороны устройства.

Я так понимаю этого д.б. достаточно чтобы на стороне РС в программе , работающей с устройством выполнить:

arp  --set         #   set a new ARP entry

вроде бы так ... ?

[zltigo 2]

определены МАС и IP со стороны устройства.

Я так понимаю этого д.б. достаточно чтобы на стороне РС в программе , работающей с устройством выполнить:

arp  --set         #   set a new ARP entry

вроде бы так ... ?

Это как-раз наоборот - определяет со стороны хоста и хосту Вы сказали. А устройство по прежднему не знает MAC хоста.... Конечно и ему забить можно намертво. А вообще, зачем так кастрировать?

Может тогда пойти до конца и вообще общаться голыми Ethenet пакетами?

[Кнкн 5]

Конечно и ему забить можно намертво. А вообще, зачем так кастрировать? может тогда пойти до конца и вообще общаться голыми Ethenet пакетами?

 

Может иметь смысл при аппаратном формировании UDP без программной поддержки.

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

[zltigo 2]

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

RAW Socket, как следует из названия, позволяет работать с тем самым сырым пакетом, правда нюансы типа прав доступа в этом случае имею место быть.

[ClockworkOrange 0]

цель минимальной поддержки (а значит упрощения), как точно подметил Кнкн - аппаратное изготовление пакетов внутри ПЛИС.

 

и тут хотелось бы найти золотой компромисс - между использованием стандартных стедств и протоколов (поддерживаемых скриптовыми языками типа TCL, Python) и простотой аппаратной реализации с другой стороны.

[psL 0]

вот http://www.fpga4fun.com/10BASE-T0.html мужик с UDP на FPGA развлекается

[ClockworkOrange 0]

вроде бы устаканилось в голове по поводу минимальной поддержки ARP. Девайс должен:

 

1) Уметь отвечать ARP-откликом (код операции = 2) на приходящие ARP-запросы (код операции = 1), (для того чтобы иметь возможность принимать пакеты с любых IP, адресованные ему).

 

2) Уметь генерировать ARP-запрос (код операции = 1) запоминатьМАС-адрес в принятом пакете ARP-отклика (код операции = 2), (для того чтобы иметь возможность отправлять пакеты на один из IP). по этому пункту некоторые вопросы: как часто вообще в сети принято обновлять ARP-таблицы (слать новые ARP-запросы)?

 

 

 

по поводу fpga4fun:

почитал. в частности: http://www.fpga4fun.com/10BASE-T2.html

там реализовано UDP + MAC + PHY для 10Мбит/с (+ заранее прописаны IPsrc, IPdst, MACsrc, MACdst)

 

вопрос спецам: одинаков ли МАС-уровень для Ethernet 100M & Ethernet 10M ??

а то слишком уж они МАС "утоптали"; и непонятно - толи это из-за оптимизации под жестко заданный тип пакета, толи из-за более простого МАС для 10М.

[ClockworkOrange 0]

просьба к администрации перенести тему в "интерфейсы" -> "Ethernet"

[Postoroniy_V 0]

вроде бы устаканилось в голове по поводу минимальной поддержки ARP. Девайс должен:

 

1) Уметь отвечать ARP-откликом (код операции = 2) на приходящие ARP-запросы (код операции = 1), (для того чтобы иметь возможность принимать пакеты с любых IP, адресованные ему).

 

2) Уметь генерировать ARP-запрос (код операции = 1) запоминатьМАС-адрес в принятом пакете ARP-отклика (код операции = 2), (для того чтобы иметь возможность отправлять пакеты на один из IP). по этому пункту некоторые вопросы: как часто вообще в сети принято обновлять ARP-таблицы (слать новые ARP-запросы)?

по поводу fpga4fun:

почитал. в частности: http://www.fpga4fun.com/10BASE-T2.html

там реализовано UDP + MAC + PHY для 10Мбит/с (+ заранее прописаны IPsrc, IPdst, MACsrc, MACdst)

 

вопрос спецам: одинаков ли МАС-уровень для Ethernet 100M & Ethernet 10M ??

а то слишком уж они МАС "утоптали"; и непонятно - толи это из-за оптимизации под жестко заданный тип пакета, толи из-за более простого МАС для 10М.

Это видели? VHDL IP Stack

[CodeWarrior1241 0]

вроде бы устаканилось в голове по поводу минимальной поддержки ARP. Девайс должен:

 

1) Уметь отвечать ARP-откликом (код операции = 2) на приходящие ARP-запросы (код операции = 1), (для того чтобы иметь возможность принимать пакеты с любых IP, адресованные ему).

 

2) Уметь генерировать ARP-запрос (код операции = 1) запоминатьМАС-адрес в принятом пакете ARP-отклика (код операции = 2), (для того чтобы иметь возможность отправлять пакеты на один из IP). по этому пункту некоторые вопросы: как часто вообще в сети принято обновлять ARP-таблицы (слать новые ARP-запросы)?

На http://www.sics.se/~adam/uip/index.html есть удобная, в моей практике, stack для TCP/IP - uIP называется. Можно выберать каке фич. нужны для чего, и есть полная документация.