По сути, вы можете свести проблему к оптимальному способу сопоставления имени операции с фактической вызываемой функцией и определения того, действительно ли нужны решения с лучшими характеристиками поиска.
- Для небольшого числа функций может быть достаточно простого решения на основе
O(n) (например, линейного поиска).
- Подход, основанный на
O(log(n)) (например, самобалансирующиеся двоичные деревья ), может быть достаточным и для большего количества операций.
- Большинство людей прыгают прямо к решению на основе хеш-таблицы из-за теоретических характеристик поиска
O(1). Однако это зависит от хорошей хэш-функции, которая сама по себе не является бесплатной с точки зрения стоимости.
Всегда присутствуют временные и пространственные компромиссы. Так что лучше всего составить профиль, прежде чем принимать решение о том, какой подход лучше всего подходит для вашего приложения.
Несмотря на это, такого рода проблемы с отправкой операций были тщательно исследованы. Например, вот один документ , в котором обсуждаются стратегии диспетчеризации операций в реализации CORBA C ++ ORB.
Помимо оптимизации поиска операций, вам, вероятно, придется иметь дело с другими факторами, такими как:
- Параллелизм : требуется ли вашему приложению параллельная обработка нескольких соединений от клиентов? Распределенный параллелизм часто очень трудно реализовать правильно.
- Сериализация : как вы будете отправлять и получать данные по сети? Проблемы, с которыми вы можете столкнуться, включают в себя: отправка простого текста может быть медленной, может потребоваться преобразование числовых значений в принимающие платформы порядковый номер , ваши протоколы сериализации могут измениться, что повлияет на ваших пользователей и т. Д.
Существует потенциально много других проблем, с которыми вам придется столкнуться и на стороне клиента. Если это вообще возможно, я бы рекомендовал использовать существующую технологию, подобную RPC, а не изобретать велосипед самостоятельно.