Проект "Свободные голосования"
http://gplvote.andyhost.ru/forum/

transport::modules::ITransportModule
http://gplvote.andyhost.ru/forum/viewtopic.php?f=21&t=193		 Страница 1 из 2
Автор:  yurial [ 09 окт 2011, 13:47 ]
Заголовок сообщения:  transport::modules::ITransportModule
Обсуждаем интерфейс транспортного модуля.
Код:
class ITransportModule
{
public:
vector<pollfd> poll() const; //man poll, man WSAPoll, man select. (windows, без поддержки poll, придется эмулировать)
int process(pollfd& fd); //обработка соединения
int send(cosnt TPacket& packet, bitset<32> group); //отправка пакета, group введено для возможности отправки по разным группам.
int recv(TRecvCallback callback); //установки функции, вызываемой при получении пакета
};

Думаю этого достаточно.
Автор:  Андрей [ 09 окт 2011, 14:23 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
Я не могу понять какой язык вы используете C++ или C#?

C# хорош для программирования, но необходимость тащить за собой Mono или .Net сильно уменьшает его преимущества.
Автор:  Андрей [ 09 окт 2011, 14:59 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
По существу - не понял назначение методов process и poll.

По идее, максимум который там нужен - init и finalize методы, которые будет вызываться при загрузке модуля. Зачем в публичных мотодех что-то, кроме передачи и получения сообщений не понял.

Кстати, есть такая хорошая библиотечка libevent. Возможно, имеет смысл использовать, что-бы не заморачиваться с низким уровнем. Я ее пробовал использовать для своих проектов - очень понравилась.
Автор:  Dim [ 09 окт 2011, 20:49 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
Андрей писал(а):
По идее, максимум который там нужен - init и finalize методы, которые будет вызываться при загрузке модуля. Зачем в публичных методах что-то, кроме передачи и получения сообщений не понял.
У меня хуже понимание. Если как транспортный модуль понимать распределённую сеть, то зачем низкоуровневые методы. А если как транспортный модуль понимать способы соединения внутри распределённой сети (tcp, udp, sctp), то их маловато. Но во втором случае на любой системе мы дефакто имеем все протоколы и не вижу причины использовать их меньше чем все. Имеет смысл подождать продолжения. :?:

Опять непонятно кто кому будет модулем. Транспорт представляющий из себя узел распределённой сети будет модулем для системы голосования или наоборот. Мне всю дорогу вдалбливали, что модулем должно быть то, что в рамках системы имеет меньшее время жизни.

Андрей писал(а):
Кстати, есть такая хорошая библиотечка libevent. Возможно, имеет смысл использовать, что-бы не заморачиваться с низким уровнем. Я ее пробовал использовать для своих проектов - очень понравилась.
А ещё есть boost::asio c портабельной реализацией сетевой системы. При этом boost это то, что "завтра" будет в stl. ;)
Автор:  Андрей [ 09 окт 2011, 21:09 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
Dim писал(а):
Андрей писал(а):
По идее, максимум который там нужен - init и finalize методы, которые будет вызываться при загрузке модуля. Зачем в публичных методах что-то, кроме передачи и получения сообщений не понял.
У меня хуже понимание. Если как транспортный модуль понимать распределённую сеть, то зачем низкоуровневые методы. А если как транспортный модуль понимать способы соединения внутри распределённой сети (tcp, udp, sctp), то их маловато. Но во втором случае на любой системе мы дефакто имеем все протоколы и не вижу причины использовать их меньше чем все. Имеет смысл подождать продолжения. :?:

При всем желании никто не сможет реализовать все эти модули одновременно. Все-равно они будут реализовываться по порядку и tcp - логичное начало.

Dim писал(а):
Опять непонятно кто кому будет модулем. Транспорт представляющий из себя узел распределённой сети будет модулем для системы голосования или наоборот. Мне всю дорогу вдалбливали, что модулем должно быть то, что в рамках системы имеет меньшее время жизни.

Транспортный модуль будет модулем в служебном сервисе (демоне).

Dim писал(а):
Андрей писал(а):
Кстати, есть такая хорошая библиотечка libevent. Возможно, имеет смысл использовать, что-бы не заморачиваться с низким уровнем. Я ее пробовал использовать для своих проектов - очень понравилась.
А ещё есть boost::asio c портабельной реализацией сетевой системы. При этом boost это то, что "завтра" будет в stl. ;)

Многие-ли проекты уже используют boost::asio?
Автор:  Dim [ 09 окт 2011, 22:39 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
Андрей писал(а):
При всем желании никто не сможет реализовать все эти модули одновременно. Все-равно они будут реализовываться по порядку и tcp - логичное начало.
Да и не надо их все сразу реализовывать. Это не причина выноса в модули. Достаточно начинать использовать протоколы по необходимости. Практически все функции можно реализовать используя только tcp. Остальные нужны только для повышения эффективности, когда уткнёмся в физические ограничения tcp.
Андрей писал(а):
Транспортный модуль будет модулем в служебном сервисе (демоне).
Какие функции у демона?
Андрей писал(а):
Многие-ли проекты уже используют boost::asio?
Не задумывался даже. Просто boost используется для обкатки того, что впоследствии входит в стандартные библиотеки языка C++. Т.е. Ваш вопрос почти аналогичен "многие ли проекты используют std::string?"
Автор:  yurial [ 10 окт 2011, 00:51 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
Андрей писал(а):
Я не могу понять какой язык вы используете C++ или C#?

С++, к C# у меня крайне негативное отношение.
Андрей писал(а):
По существу - не понял назначение методов process и poll.

Для ожидания событий связанных с соединениями.
Андрей писал(а):
Кстати, есть такая хорошая библиотечка libevent.

Судя по описаниям - как раз то, что я хотел реализовать с помощью poll.
Изучу возможности библиотеки - выскажу мнение.
Dim писал(а):
А ещё есть boost::asio c портабельной реализацией сетевой системы. При этом boost это то, что "завтра" будет в stl. ;)

На данный момент boost меня немного пугает.
ps по поводу модулей - хуже ведь от них не станет? Каждый сможет особо не заморачиваясь написать свой собственный модуль.
Автор:  Dim [ 10 окт 2011, 01:21 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
Dim писал(а):
На данный момент boost меня немного пугает.
Если не касаться метапрограммирования, то в нём ничего страшного и нет.
Dim писал(а):
ps по поводу модулей - хуже ведь от них не станет? Каждый сможет особо не заморачиваясь написать свой собственный модуль.
C++ не Java. Несколько лет назад читал довольно объёмную статью о "прелестях и радостях" построения системы плагинов для C++ в условиях кроссплатформной и кросскомпиляторной разработки. Вводная часть изобиловала выражениями типа: не обязан, не гарантирует, неопределённый результат.
При этом в целом являясь сторонником плагинов считаю, что применять их следует с большой осторожностью и там где по другому никак не обойтись.
Автор:  yurial [ 10 окт 2011, 11:14 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
Dim писал(а):
Если не касаться метапрограммирования, то в нём ничего страшного и нет.

Мета-программирование меня не пугает, меня пугает размер библиотеки, и то что ее повсюду придется таскать. При веских аргументах я готов попробовать boost. Dim, а у вас собственно есть опыт работы с boost?
Dim писал(а):
C++ не Java. Несколько лет назад читал довольно объёмную статью о "прелестях и радостях" построения системы плагинов для C++ в условиях кроссплатформной и кросскомпиляторной разработки. Вводная часть изобиловала выражениями типа: не обязан, не гарантирует, неопределённый результат.
При этом в целом являясь сторонником плагинов считаю, что применять их следует с большой осторожностью и там где по другому никак не обойтись.

Могли бы вы найти подобную статью. Лично я проблем не вижу: существуют лишь некоторые ограничения.
Автор:  Андрей [ 10 окт 2011, 12:16 ]
Заголовок сообщения:  Re: transport::modules::ITransportModule
Dim писал(а):
Андрей писал(а):
При всем желании никто не сможет реализовать все эти модули одновременно. Все-равно они будут реализовываться по порядку и tcp - логичное начало.
Да и не надо их все сразу реализовывать. Это не причина выноса в модули. Достаточно начинать использовать протоколы по необходимости. Практически все функции можно реализовать используя только tcp. Остальные нужны только для повышения эффективности, когда уткнёмся в физические ограничения tcp.

Причина выноса в модули - потенциал для дальнейшего развития. Что-бы в будущем в систему можно было, например, быстро добавить поддержку FreeNet, I2P или других распределенных сетей.

Dim писал(а):
Андрей писал(а):
Транспортный модуль будет модулем в служебном сервисе (демоне).
Какие функции у демона?

Насколько я понимаю, демон будет заниматься тем, что нужно делать даже когда пользователь его не использует - транзитные пересылки, хранение части информации распределенной сети, ответы на запросы и т.д.

Dim писал(а):
Андрей писал(а):
Многие-ли проекты уже используют boost::asio?
Не задумывался даже. Просто boost используется для обкатки того, что впоследствии входит в стандартные библиотеки языка C++. Т.е. Ваш вопрос почти аналогичен "многие ли проекты используют std::string?"

Я к тому, что нужно выбирать хотя-бы немного опробованные инструменты. Заниматься их тестированием в контексте нашего проекта - это конечно неплохо для этих инструментов, но плохо для нашего проекта. Насколько я знаю, предложенная мною библиотека libevent уже используется в очень многих проектах. Что позволяет надеяться на ее качество.
Страница 1 из 2 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/