192 / 199 / 82
Регистрация: 11.04.2013
Сообщений: 1,086
|
|
1 | |
сокеты непонятные моменты17.04.2013, 18:39. Показов 1191. Ответов 15
Метки нет (Все метки)
1. Как выбрать оптимальный размер буфера?
Я понимаю что можно поставить и 1 байт данные все равно все будут получены (TCP/IP) , можно выставить такой же как у получателя/отправителя, но что если он там к примеру гигабайт...... 2. Если не известно количество получаемых данных , а известен только байт конца посылки (принимает асинхронный клиент) Callbackrecive { считали пакет if(нет символа конца посылки) Beginrecive } Что то мне напоминает это замкнутый цикл, не нарушается ли здесь принцип асинхронности , может в таком случае правление будет сделать клиента синхронного ?
0
|
17.04.2013, 18:39 | |
Ответы с готовыми решениями:
15
Непонятные моменты из книги Фроловых А. и Г. "C# для начинающих" DllImport из с++ подскажите непонятные моменты Непонятные моменты языка Прокомментировать непонятные моменты |
17.04.2013, 19:11 | 2 |
Не по теме: как по мне, второй самый оптимальный Могу ошибаться, но должно быть два буфера: для получения набора байт из потока (скажем 1000 байт) и ещё один для записи текущего сообщения (MemoryStream). Первый выполняет прием блока данных, смотрит нет ли в нем конца сообщения, закидывает в MemoryStream и продолжает чтение, если нужно. Все это крутится в отдельном потоке, не блокируя главного. Это и есть принцип асинхронности.
0
|
192 / 199 / 82
Регистрация: 11.04.2013
Сообщений: 1,086
|
|
17.04.2013, 19:27 [ТС] | 3 |
0
|
Администратор
|
|
17.04.2013, 19:55 | 4 |
Тогда уж 1024 байта, по аналогии с буферизованным вводом/выводом на диск. Хотя, может быть, на этот показатель размер буфера не влияет, всё-таки аналогия косвенная.
0
|
17.04.2013, 19:58 | 5 |
Точно не знаю, но вроде-как асинхронный метод работает чуть быстрее, чем вызов синхронного в отдельном потоке. Но в конечном итоге, Callbackrecive будет работать в отдельном потоке. И как по мне - такой подход более понятней и наглядней, чем вызов новых Thread.
У самого сокета тоже есть буфер, теоретически нужно подстраиваться под него. Но у меня было некоторое "но": длина сообщений варьировала от 200 байт до 1 Мбайт. Я просто поставил 1024, потому-что мне нравится это число и особо не углублялса.
0
|
Администратор
|
||||||
17.04.2013, 20:12 | 6 | |||||
Асинхронный метод тоже работает в отдельном потоке. Вот пример из MSDN:
Кликните здесь для просмотра всего текста
Как видите, метод вызванный через BeginInvoke() работает в потоке №3, а основной поток - 1. Откуда тогда выигрыш в производительности?
0
|
192 / 199 / 82
Регистрация: 11.04.2013
Сообщений: 1,086
|
|
18.04.2013, 06:35 [ТС] | 7 |
Вот и мне кажется что что для клиентского приложения выигрыша никакого не будет , есть смысл делать клиента асинхронным если это скажем чат , а если требуется получать большие объемы информации то по моему синхронный в отдельном потоке будет лучше ?
0
|
Администратор
|
|
18.04.2013, 08:12 | 8 |
Видимо мы опять говорим про разные вещи. Если в MSDN открыть статью "Асинхронные методы", то там описаны способы запуска метода не заморачиваясь с потоками самостоятельно (через BeginInvoke()/EndInvoke()). Однако поток всё-равно будет создан, только здесь его создают за вас, а напрямую (создавая новый объект Thread) вы сами его создаёте - в итоге разницы никакой.
Возможно, под выражением "асинхронный метод" вы имеете ввиду что-то другое, поэтому и говорим мы про разные вещи. В общем Wolfdp советует вам запустить приём данных в отдельном потоке - неважно как: через BeginInvoke, Thread() или через Task или ещё как-угодно - ваше приложение не будет зависать во время приёма данных, если всё сделать правильно.
0
|
192 / 199 / 82
Регистрация: 11.04.2013
Сообщений: 1,086
|
|
18.04.2013, 19:04 [ТС] | 11 |
Callbackrecive
{ считали пакет if(нет символа конца посылки) Beginrecive } Мне не нравиться эта конструкция мне кажется это как то криво
0
|
18.04.2013, 21:51 | 12 |
Когда кажется, крестится нужно. Все зависит от задачи - идет прослушка входных сообщений или просто прием блока данных. А проверок будет, у-у-у-у-у... Для начала, нужно проверять, сколько реально пришло байт, а то бывает запрашиваем 100, а приходит только 50. Второе - если буфер размером 100, а с той стороны нам отсылают два сообщения по 20, то мы примем один кусок длиной 40.
Можно просто один раз вызвать BeginRecive, и уже в Callbackrecive организовать замкнутый цикл, который будет там постоянно крутится в выделенном потоке.
0
|
192 / 199 / 82
Регистрация: 11.04.2013
Сообщений: 1,086
|
|
19.04.2013, 08:01 [ТС] | 13 |
Wolfdp, север активный и написанный давно, не принимает ни каких данных от клиента (собирает данные со скады через DDE), при конекте клиента шлет ему пакет архивных данный от 1 до 15 метров (есть символ конца посылки), потом постоянно раз в 10 секунд высылает текущие данные...
Зачем мне заморачиваться и проверять сколько байт пришло, когда я могу просто читать данные пока не получу символ конца посылки и не важно как там разбились пакеты , я правильно думаю?
0
|
19.04.2013, 09:02 | 14 | |||||
0
|
192 / 199 / 82
Регистрация: 11.04.2013
Сообщений: 1,086
|
|
19.04.2013, 10:01 [ТС] | 15 |
Wolfdp
как правильно сделать в моем случае чтобы по минимуму нагружать сервер передающий данные , и машину которая получает данные 1. считать архив синхронно , а потом получать текущие данные асинхронно 2. считывать все синхронно 3. считывать все асинхронно 4. по барабану
0
|
19.04.2013, 21:11 | 16 |
Если вы пишите сервер и нужно предусмотреть возможность одновременного подключения n-пользователей, то по любому придется использовать асинхронную отправку (Thread или BeginSend). Клиент тоже желательно сделать асинхронным, чтобы не висла программа на методе Recive.
Насчет нагрузки ничего подсказать не могу.
0
|
19.04.2013, 21:11 | |
19.04.2013, 21:11 | |
Помогаю со студенческими работами здесь
16
Непонятные моменты с полумостом. Непонятные моменты из Страуструпа и не только Есть непонятные моменты по хтмл и ксс Некоторые непонятные моменты насчёт Паскаля Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |