Pipe server
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 29.03.11 07:23
Оценка:
Добрый день.
Я пишу клиент серверное приложение на основе именованых pipe-ов(windows, 4-й фреймверк). Pipe-ы были выбраны в качестве основного транспортного механизма по одной простой причине — клиент и сервер работают на одной машине. На разных машинах они не будут работать никогда и это нужно учесть при разработке архитектуры приложения.
Первое, что пришло мне в голову — асинхронный pipe-сервер. Клиент push-ит запрос серверу, сервер, получает запрос, декодирует его(используется google protobuf), затем вычисляет ответ и передает его потребителю. Код потребителя зависит от приложения(CPU bound), потребитель выполняет некоторую работу и push-ит ответ клиенту, помимо этого, ответ может быть не один, либо, портебитель может изменить свое состояние в ответ на запрос и ничего не послылать клиенту. В общем, потребитель это некий КА, который не выполняет никакого I/O, просто формирует ответ и ставит его в очередь на передачу.
Код сервера и потребителя, естественно разделены. Я реализовал асинхронный сервер, а затем на его основе — простой эхо сервер, для тестов. Латентность операции запрос-ответ у меня получилась порядка 100μs.
Затем, я реализовал синхронный сервер. Синхронный сервер читает запрос из пайпа, переадет его потребителю(бизнес логика приложения), который затем записывает в пайп ответ. Все это в отдельном потоке. Для этого случая я также реализовал простой эхо сервер, латентность запрос-ответ — 35μs, что не может не радовать. Однако, этот вариант является менее масштабируемым, так как придется создавать на каждое подключение, как минимум по одному треду, либо несколько тредов, если потребуется конвееризация этапов выполнения запроса. С другой стороны, клиенты и сервер всегда работают на одной машине, поэтому очень большая мастабируемость и не нужна. В тоже время, хотелось бы получить минимальную латентность, избежать по возможности лишней буферизации данных между клиентами и сервером.
Вообще, я сейчас склоняюсь к такому варианту, потребитель запросов реализуется в виде потока, наследника Stream. Данные из пайпа перенаправляются в этот поток — pipe.CopyTo(consumer); потребитель имеет рабочий поток, в котором он обрабатывает данные и выдает поток ответов. Затем этот поток перенаправляется потребителю.
В общем, помогите мне принять решение, возможно я что-то упускаю.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.