Внутренняя организация мультипоточного сервера
Доброе время суток всем!
Буду рад, если кто-нибудь поделится идеями о внутренней организации мультипоточного сервера-посредника для следующей системы:
к компу подключены железки. Железки общаются между собой через CAN. Объединены между собой в кольца. Кольца подключаются к компу через разные преобразователи интерфейса (CAN-USB, CAN-Ethernet, и т.д.)
На компе имеются приложения для работы с этими железками. Между приложениями и кольцами с железками - сервер-посредник.
Обязанности сервера:
- прием запросов от приложений, обработка этих запросов, передача их нужным железкам (реализация запросов часто представляет собой комбинацию передачи и приема элементарных команд)
- передача элементарных команд от железок всем приложениям (железки могут не только отвечать на запросы, но и сами генерировать сообщения)
- при производстве блочного запроса к одной из железок внутри кольца обмен сообщениями с остальными железками в этом кольце блокироваться не должен
попытался нарисовать: http://xmages.net/upload/6bdcdf29.jpg
сейчас сам думаю пока организовать как-то так: http://xmages.net/upload/bd6015e4.jpg
Буду рад, если кто-нибудь поделится идеями о внутренней организации мультипоточного сервера-посредника для следующей системы:
к компу подключены железки. Железки общаются между собой через CAN. Объединены между собой в кольца. Кольца подключаются к компу через разные преобразователи интерфейса (CAN-USB, CAN-Ethernet, и т.д.)
На компе имеются приложения для работы с этими железками. Между приложениями и кольцами с железками - сервер-посредник.
Обязанности сервера:
- прием запросов от приложений, обработка этих запросов, передача их нужным железкам (реализация запросов часто представляет собой комбинацию передачи и приема элементарных команд)
- передача элементарных команд от железок всем приложениям (железки могут не только отвечать на запросы, но и сами генерировать сообщения)
- при производстве блочного запроса к одной из железок внутри кольца обмен сообщениями с остальными железками в этом кольце блокироваться не должен
попытался нарисовать: http://xmages.net/upload/6bdcdf29.jpg
сейчас сам думаю пока организовать как-то так: http://xmages.net/upload/bd6015e4.jpg
Попытаюсь вникнуть (и вспомнить) с помощью уточняющих вопросов.
Цитата: Нездешний
- при производстве блочного запроса к одной из железок внутри кольца обмен сообщениями с остальными железками в этом кольце блокироваться не должен
Разве CAN не решает такие проблемы самостоятельно на основе приоритетов?
Разве не достаточно просто сделать 2 потока: отправляющий кадры и принимающий кадры? А уж принятое как-то сортировать на основе идентификаторов.
Заметь, я работаю с CAN через интерфейс некоего преобразователя (CAN-USB, CAN-Ethernet). Протоколы взаимодействия с преобразователями разные. Одновременно каждого вида преобразователей (соответственно, и колец с железяками) может быть подключено несколько.
Кроме отдельных "кадров"-сообщений необходимо реализовать еще некоторые составные запросы. Например, есть составной запрос по прошивке flash железки. Выглядит примерно так:
Железка - Приложение
<- запрос протокола обмена
-> ответ (ожидание с таймаутом)
<- служебные команды для подготовки железки к смене содержимого flash
-> ответ "готово" (ожидание с таймаутом)
<- отсылка N сообщений с новым содержимым flash
<- запрос контрольной суммы
-> ответ (ожидание с таймаутом)
Все это одна составная операция. Представь, что нужно выполнить две (или более) таких операций одновременно с разными железками в одном кольце. Одним потоком на запись и одним на чтение вряд ли обойдешься
Кроме отдельных "кадров"-сообщений необходимо реализовать еще некоторые составные запросы. Например, есть составной запрос по прошивке flash железки. Выглядит примерно так:
Железка - Приложение
<- запрос протокола обмена
-> ответ (ожидание с таймаутом)
<- служебные команды для подготовки железки к смене содержимого flash
-> ответ "готово" (ожидание с таймаутом)
<- отсылка N сообщений с новым содержимым flash
<- запрос контрольной суммы
-> ответ (ожидание с таймаутом)
Все это одна составная операция. Представь, что нужно выполнить две (или более) таких операций одновременно с разными железками в одном кольце. Одним потоком на запись и одним на чтение вряд ли обойдешься
Цитата: Нездешний
Заметь, я работаю с CAN через интерфейс некоего преобразователя (CAN-USB, CAN-Ethernet). Протоколы взаимодействия с преобразователями разные. Одновременно каждого вида преобразователей (соответственно, и колец с железяками) может быть подключено несколько.
Это не важно, так как говорилось про блокирование в одном кольце.
Цитата: Нездешний
Кроме отдельных "кадров"-сообщений необходимо реализовать еще некоторые составные запросы.
Просто у тебя сервер слишком "интеллектуальный". Ещё и составные запросы должен обрабатывать. Но если и так, то можно на каждый составной запрос генерировать отдельный процесс и воспринимать его как отдельное приложение. Хотя, может я уже слишком абстрактно начал рассуждать.
Хотя... кажется я тебя понял. Если передать обязанность реализации сложных операций "поближе" к приложениям, то можно обойтись одним потоком на прием, и одним - на передачу
http://xmages.net/upload/505c43a4.jpghttp://xmages.net/upload/505c43a4.jpg
Возникает вопрос синхронизации. Как узнать что сообщение из очереди принятых уже обработано всеми "клиентами" и его можно удалить из очереди?
Может, сделать для каждого свою очередь и свой механизм синхронизации доступа (например, критическую секцию)...
http://xmages.net/upload/505c43a4.jpghttp://xmages.net/upload/505c43a4.jpg
Возникает вопрос синхронизации. Как узнать что сообщение из очереди принятых уже обработано всеми "клиентами" и его можно удалить из очереди?
Может, сделать для каждого свою очередь и свой механизм синхронизации доступа (например, критическую секцию)...
Цитата: Kogrom
Просто у тебя сервер слишком "интеллектуальный". Ещё и составные запросы должен обрабатывать
Основная причина создания этого сервера - абстрагирование приложений от способа связи с CAN и от конкретной версии протокола обмена составными запросами