Zemetrans
commented
8 years ago 
1) Устройство, появляясь в сети, шлёт remote frame в сеть, CAN_ID устройства занимает 8 байт, в которых размещаются MAGIC AJ и ID устройства. 2) Сервер сохраняет CAN_ID клиента, выделяет и запоминает уникальный ID серии, далее отвечает расширенным кадром, где первый младший байт CAN_ID занимает MAGIC AJ и ID устройства назначения, второй младший байт MAGIC AJ и ID источника. В первом байте data расположен уникальный ID серии. 3) Клиент получает расширенный кадр, и сохраняет свой ID серии. Далее, кадры предназначенные клиенты будут содержать в младшем байте CAN_ID уникальный ID серии.
fulcrum7
Добрый день! Пока реализовал в общих чертах передачу клиент -> сервер а дальше заблокировался:
Когда придумывал протокол как-то не учёл-забыл, что CAN сеть отличается от TCP/IP и всё вещание идёт только широковещательно. Текущие проблемы:
1) can_raw сокеты могут вызывать только bind и стандартную очередь с помощью listen не создашь. Тут разберусь сам, смотрел исходники can-utils, там они размноживают сырые сокеты, додумаю.
2) конфликт "много клиентов - один сервер" не решается тем форматом кадров, что я придумал, надо менять. Нужно как-то добавить адресацию, чтобы клиенты получали только те кадры, которые им предназначены и не вылавливали кадры, принадлежащие нашему протоколу, но отправленные не им. Будет проблема, когда 2'клиента ожидают информационные кадры одновременно, а потом хватают не своё. Есть идея размещать в data полях can Id, но тогда в каждом кадре 4 байта будут всегда занятыми. Наверное это будет костылем, да?