вопрос к знатокам:
а что нужно (какая поддержка в движке), чтобы
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 не содержится МАС-адреса, т.е. мягко говоря не совсем понятно как он будет ходить по сети ((.

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

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

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

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

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

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

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

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

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

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

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

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

заодно удалось накопать что-то на русском:
http://book.itep.ru/4/44/arp_446.htm
http://www.protocols.ru/files/RFC/rfc826.pdf

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

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

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

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

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

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

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

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

вроде бы устаканилось в голове по поводу минимальной поддержки 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М.

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

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

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

>> Это видели? VHDL IP Stack
если бы они исходники выложили.. а то так.. "тезисы докладов" написали...

>> На http://www.sics.se/~adam/uip/index.html есть удобная, в моей практике,
>> stack для TCP/IP - uIP называется ... и есть полная документация.
спасибо. грамотная документация это тоже хорошо.
но хотелось бы засунуть всё в эдакую statemashine внутре FPGA.
минимизировать ресурсы, упростив всё до аскетизма.

http://www.itee.uq.edu.au/~peters/xsvboard/stack/stack.pdf
http://www.itee.uq.edu.au/~peters/xsvboard.../stackfiles.zip

Обычное время жизни маков ~200-300 секунд.
Вот здесь хорошо и четко раписано как строятся протоколы http://book.itep.ru/1/intro1.htm
Вообще для простоты лучше отказаться от UDP...Используйте Ethernet для передачи. Это будет проще.

Алгоритм раьоты может быть таким:
1) Широковещательны запрос (бродкаст) -->
2) Ответы от всех устройств, которые ждут такого зпроса <--
3) Передача данных на мак-адрес выбранного устройства -->
Вообще первые 2 пункта нужны если надо проверить присутствие девайса в сети. Такая схема поможет не заморачитваться с IP уровнем.

Свои пять копеек...
По поводу минимизации ресурсов...
Если делать IP+UDP, то нужно определиться будете ли Вы принимать дефрагментированные пакеты (IP уровень). Больше всего распространён размер в 1500 байт..далее идёт дефрагментация (если флажок не запрещает)...

Если дефрагментация - то это буффер, если буффер - время жизни данных и т.д..

с уважением
(круглый)

Если устройство находится в подсети (особенно, если в ней присутствует еще какое-то кол-во других Ethernet устройств), в которой IP адреса устройствам назначает DHCP сервер, то в проектируемом устройстве также необходимо поддержать DHCP, иначе нужно будет все время бегать к сис.админу и уточнять список назначенных IP адресов сервером, и назначать вручную устройству не занятый IP адрес. Что есть криво. Или посылать ICMP запросы в сеть и удостоверяться, что по опрошенному IP никто "не сидит" и тогда его занимать. Что точно также криво, особенно если временно отсутствующий узел, который мы заняли, вдруг решил включиться и появиться в сети. Короче говоря, конфликты обеспечены.