LINUX.ORG.RU

Proactor


1

1

Есть сетевой стек. В нем три службы: получатели, обработчки и отправители. Каждая из этих служб - пул потоков с очередью. Еще есть диспетчер, который ждет на epoll и при доступности ввода по некоторым дескрипторам сабмитит дескриптор в очередь получателей и сразу продолжает прослушивание по оставшимся декскрипторам. Получатель скачав все что надо и собрав сообщение передает готовое сообщение обработчику, который может асинхронно засабмитить любое количество сообщений отправителям.

Это и есть Proactor pattern? Написал сие чудо, теперь нагуглил что все можно описать одним словом, лишь уточнив что есть три службы

★★★★★

Дополнительный вопрос. В какой книге proactor pattern качественно описан? Интересует именно книга, поскольку интересно не только его описание, а также библиографические ссылки.

anonymous
()
Ответ на: комментарий от anonymous

Я видел только ресурсы онлайн. Внизу могут быть ссылки на книги. Но относительно «качественно», то думаю нет, иначе бы я не задавал глупых вопросов. Вообще я понял что это такое, но там кажется указано, что начальный read должен быть вызван ядром, у меня же диспетчер занимается обычными polling, что свойственно паттерну Reactor. Но он сразу передает обработку дальше, последующая обработка происходит асинхронно в отдельных службах. Тоесть диспетчер сразу же возвращается назад к прослушиванию набора дескрипторов, что НЕ свойственно паттерну Reactor. Потому у меня кажется решение гибридное

vertexua ★★★★★
() автор топика

Погуглил. Оказалось что моя система - гибрид Reactor (на первом шаге) и SEDA (на остальных).

Таким образом если в Java NIO нет event-driven IO, чего если память не изменяет вообще говоря не во всех ОС есть, то моя система реализуема, а чистая SEDA - нет.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от jtootf

В Java нет, разве что в NIO.2. Но когда я писал подобное на .NET, где такое есть, то откушал прекрасного кактуса, когда на эти все eventы использовался какой-то скрытый внутри или .NET или Windows thread pool, который не поддавался кофигурированию и таким образом не соблюдался баланс чтения и записи. В итоге через 5 минут активной работы все ноды уходили в запись, а все евенты, отвечающие за чтение находились в какой-то внутренней очереди, не знаю точно (откуда тут узнаешь), но по крайней мере не вызывались. Отследить это можно было только Microsoft Visual Studio Parallel Stacks, которая показала глобальный сетевой Write в большом количестве экземпляров и ни одного Read.

Воообще кактус получился из-за того, что все было асинхронным, думаю записывать можна было бы и явно, через Thread Pool. Но почему тогда MS говорит что все должно быть пучком?

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Вообще когда будет Java 7, то возможно перепишу. Пока кроссплатформенных решений нет. Есть уже готовые сетевые стеки, такие как Grizzly, Netty, MINA, думаю дать к ним доступ через интерфейс, чтобы они были Pluggable на ряду с моей реализацией.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Естественно, я же больше ничего не умею.

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

> использовался какой-то скрытый внутри или .NET или Windows thread pool,

CreateThreadpool/CloseThreadpool

который не поддавался кофигурированию


4.2

SetThreadpool*

Воообще кактус получился из-за того, что все было асинхронным


Но почему тогда MS говорит что все должно быть пучком?


Ты сделал что-то не так.

К.О.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

А, ну понятно. Просто в WinAPI я знаю. Тут была проблема в том как указать кто будет выполнять callbacks ReadBegin

vertexua ★★★★★
() автор топика

Книгу еще подскажу, там и реактор, и проактор, pdf гуглится легко:

«pattern-oriented software architecture volume 2»

ratatosk
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.