Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Работа с асинхронными сокетами.  (Прочитано 6184 раз)
0 Пользователей и 1 Гость смотрят эту тему.
x128
Интересующийся

ru
Offline Offline

« : 28-07-2010 17:07 » 

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

ru
Offline Offline
Сообщений: 13


« Ответ #1 : 28-07-2010 17:16 » 

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

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

x128
Интересующийся

ru
Offline Offline

« Ответ #2 : 28-07-2010 17:24 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 28-07-2010 17:24 » 

x128, для сферического приложения в вакууме - индифферентно Улыбаюсь
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
x128
Интересующийся

ru
Offline Offline

« Ответ #4 : 28-07-2010 17:33 » 

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 28-07-2010 17:48 » 

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

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

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

Если программа получает 1 пакет в сутки, а время его обработки - 1 мкс, то асинхронность тут нафиг не нужна. Если программа слушает гигабитный интерфейс, загруженный под завязку - вот тут уже можно что-то обсуждать: потоки тут выгоднее, мультиплексирование или ещё как.
« Последнее редактирование: 28-07-2010 17:50 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
x128
Интересующийся

ru
Offline Offline

« Ответ #6 : 28-07-2010 18:03 » 

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 28-07-2010 18:16 » 

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

Цитата: x128
БД MS SQL Compact встроенный, количество конектов <= 100. Ну где то так.
Пока ты не изложишь внятные спецификации по нагрузкам и требуемому быстродействию, ответа не будет. Мне правда лень за тебя их продумывать.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
x128
Интересующийся

ru
Offline Offline

« Ответ #8 : 28-07-2010 18:27 » 


Цитата: x128
БД MS SQL Compact встроенный, количество конектов <= 100. Ну где то так.
Пока ты не изложишь внятные спецификации по нагрузкам и требуемому быстродействию, ответа не будет. Мне правда лень за тебя их продумывать.

 Здесь была моя ладья... Ну библиотеку я уже сделал. Ладно извиняюсь за беспокойство. Улыбаюсь
Записан
x128
Интересующийся

ru
Offline Offline

« Ответ #9 : 31-07-2010 06:45 » 

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

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

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 31-07-2010 09:39 » 

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

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

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

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

Цитата: x128
А почему потоки будет выгодней?
Я такого не говорил. Я сказал, что нужно думать и обсуждать, какое именно решение будет выгоднее.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
x128
Интересующийся

ru
Offline Offline

« Ответ #11 : 02-08-2010 10:49 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #12 : 02-08-2010 12:29 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines