Организация передачи потока данных АЦП через Ethernet (UDP) - как не изобретать велосипед?, Как наиболее стандартно это сделать? Опции

[Ruslan1]

Здравствуйте,

Есть такая задачка:
8-канальный 24-битный АЦП выдает данные 1000 сэмплов в секунду.
То есть трафик полезных передаваемых данных: 8 каналов * 24 бита * 1000 сэмплов = 192 Килобита в секунду (плюс еще мелочь вроде текущего времени)

Нужно передавать этот поток в канал Ethernet. Супернадежность не нужна, потеря фрейма не страшна. По всем критериям UDP подходит.
генерировать фреймы проблемы не вижу, проблема как это сделать так, чтобы с принимающей стороны это было просто принимать и обрабатывать.

Может быть, есть более-менее стандартные (популярные) методики для передачи подобной информации, например, какие-нибудь АЦП модуль с Езернетом, и на них известен формат фрейма?
Или, может быть, несложно сделать так чтобы со стороны принимающего компьютера это выглядело как удаленный виртуальный COM-порт (с уникальным IP и port) ?

Какие подводные камни могут быть? возможно ли, чтобы несколько приемников(компьютеров) принимали эти UDP дэйтаграммы (вроде бы да) ?

например, нашел у lcard.ru похожие устройства с UDP.

[gerber]

Супернадежность не нужна, потеря фрейма не страшна. По всем критериям UDP подходит.

Не подходит. На первом же коммутаторе два пакета UDP вполне себе могут "поменяться местами", то есть отправленный позже пакет придёт раньше. Думаю, что для АЦП данных это критично.

[Ruslan1]

Не подходит. На первом же коммутаторе два пакета UDP вполне себе могут "поменяться местами", то есть отправленный позже пакет придёт раньше. Думаю, что для АЦП данных это критично.

Я однозначно в каждый UDP пакет буду вставлять время первого сэмпла в начало (опять же вопрос что вставлять, пока что склоняюсь к 4-байтовому числу формата time_t плюс 2-байтовый номер миллисекунды).

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