Работа с асинхронными сокетами.

[x128]

Что лучше для северного приложения: "Асинхронный приём и синхронная отправка данных, или асинхронный приём и асинхронная отправка данных?"
Пока выбран первый вариант. Может второй лучше?

[Алексей++]

а разве отправка бывает асинхронная ?

то есть - отдельно от приёма как определить синхронность то

[x128]

Тут имеется в виду асинхронная запись в NetWorkStream, методы BeginWrite и EndWrite. Типа асинхронно получили данные, обработали их и асинхронно отправили.

[Dimka]

x128, для сферического приложения в вакууме - индифферентно

[x128]

x128, для сферического приложения в вакууме - индифферентно

У меня мыслится такая архитектура. Для каждого подключения создаётся объект, который работает следующим образом:"Асинхронно получили входной пакет, из него получили объект, из объекта получили используя БД объект для отправки клиенту, из него получаем выходной пакет, пакет отправляем клиенту. И всё это делается в методе обратного вызова для BeginRead.

[Dimka]

Придётся пояснить.

x128, любое приложение решает какую-то конкретную задачу в конкретных условиях: минимальные условия эксплуатации (так что если программа их не обеспечивает, то не нужна вовсе), максимальные нагрузки (на что программа способна на определённом железе).

Ты не назвал никаких параметров, по которым можно вообще ставить вопрос о выборе той или иной архитектуры.

Если программа получает 1 пакет в сутки, а время его обработки - 1 мкс, то асинхронность тут нафиг не нужна. Если программа слушает гигабитный интерфейс, загруженный под завязку - вот тут уже можно что-то обсуждать: потоки тут выгоднее, мультиплексирование или ещё как.

[x128]

Dimka, сервер - обычный комп в локалке, БД MS SQL Compact встроенный, количество конектов <= 100. Ну где то так.

Дело ещё в том что я пишу библиотеку под приложение, и хотелось бы её сделать такой что бы её можно было использовать во многих случаях реализуя только логику работы сервера, а отправку и приём данных доверить библиотеке:)

[Dimka]

Дело ещё в том что я пишу библиотеку под приложение, и хотелось бы её сделать такой что бы её можно было использовать во многих случаях реализуя только логику работы сервера, а отправку и приём данных доверить библиотеке:)

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

БД MS SQL Compact встроенный, количество конектов <= 100. Ну где то так.

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

[x128]

БД MS SQL Compact встроенный, количество конектов <= 100. Ну где то так.

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

  Ну библиотеку я уже сделал. Ладно извиняюсь за беспокойство.

[x128]

Придётся пояснить.

x128, любое приложение решает какую-то конкретную задачу в конкретных условиях: минимальные условия эксплуатации (так что если программа их не обеспечивает, то не нужна вовсе), максимальные нагрузки (на что программа способна на определённом железе).

Ты не назвал никаких параметров, по которым можно вообще ставить вопрос о выборе той или иной архитектуры.

Если программа получает 1 пакет в сутки, а время его обработки - 1 мкс, то асинхронность тут нафиг не нужна. Если программа слушает гигабитный интерфейс, загруженный под завязку - вот тут уже можно что-то обсуждать: потоки тут выгоднее, мультиплексирование или ещё как.

А почему потоки будет выгодней? У меня в приведённом варианте издержки с переключением между потоками, присутствуют на всех этапах обработки запроса.
Вообще на эту тему что ли бо внятного  для Net в интернете на нашёл. Только вот это: http://www.microsoft.com/Rus/Msdn/Magazine/2005/08/Winsock.mspx
Но там автор делает упор на способность сервера держать много подключений, а не на его быстродействии. Может подскажите где инфу на эту тему можно найти. А

[Dimka]

x128, вот как бы тебе объяснить, что твой исходный вопрос непонятен...

У тебя должна быть задача и условия работы, которые ты так и не озвучил. По делу ты говоришь почему-то "между делом":

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

Во, оказывается, быстродействие для тебя важнее количества подключений.

Изложи подробно, что тебе надо, и только тогда тебе смогут дать полезный совет. Что такое по-твоему "хорошее" решение: какие параметры каким числовыми значениями должны обладать, чтобы ты сказал, что это "хорошо"?

Вообще на эту тему что ли бо внятного  для Net в интернете на нашёл.

Данная тема больше об архитектуре. В ней нет ничего .NET-специфичного. Именно поэтому ты ничего не находишь для .NET. Но это не значит, что .NET какой-то неподходящий. Ты просто ищешь готовое решение, которое никто не описывал. И у тебя есть шанс стать первым, кто это решение опишет, когда реализует.

А почему потоки будет выгодней?

Я такого не говорил. Я сказал, что нужно думать и обсуждать, какое именно решение будет выгоднее.

[x128]

Цифр конкретных нет, я просто хочу сделать такую архитектуру:"Модуль приёма пакета - очередь - модуль парсинга - модуль обработки
 - модуль создания пакета-очередь(буфер) - модуль отправки пакета. Модуль парсинга, обработки, и создания пакета будет работать в одном потоке. Осталось только определится с модулями приём и отправки.    Что тут лучше использовать асинхронные сокеты или Select?

[RXL]

x128, как выше написано - предмета разговора нет, потому сравнение "лучше" не применимо. Делай так, как лучше знаешь или как хочется сделать.