информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Портрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Очередное исследование 19 миллиардов... 
 Оптимизация ввода-вывода как инструмент... 
 Зловреды выбирают Lisp и Delphi 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
если вы видите этот текст, отключите в настройках форума использование JavaScript
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
Читай ffff байт не прогадаешь 08.05.02 08:11  Число просмотров: 1050
Автор: Killer{R} Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Читай ffff байт не прогадаешь, а recv возвратит сколько рельно прочитано.
<programming>
[Net] Проблема с WSAAsyncSelect 07.05.02 10:56  
Автор: mijk Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Если в сокет (IPPROTO_TCP) пришло, например, 50 байтов, а я в обработчике сообщения FD_READ даю команду recv (или WSARecv) с размером буфера 20 байтов, то сначала возвращаются последние 10 байтов сообщения, вновь возникает событие FD_READ, последующая команда recv возвращает байты 20-39, в следующий раз возвращаются первые 20 байтов. В чем проблема? Или так и должно быть? Как тогда правильно обрабатывать данные, я же не могу предугадать размер поступивших данных? На codeguru посоветовали использовать модель select, но меня устраивает именно асинхронная модель WSAAsyncSelect, все равно алгоритм на интерфейс завязан.
[Net] Проблема с WSAAsyncSelect (ошибка в программе) 13.05.02 10:05  
Автор: vp016 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
исходя из того что написано в РФС данные могут приходить частями из-за фрагментации (т.е. блок отправил - он пришел частями). Это не зависит от того как ты данные получаешь (асинхронно - это завист от того как система отдает с сокета данные и никоим образон не влияет на получение данных самой системой). Вот последовательность данных - ВСЕГДА дожна сохранятся (определение протокола).
Так что ищи ошибку у себя в проге.
Читай ffff байт не прогадаешь 08.05.02 08:11  
Автор: Killer{R} Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Читай ffff байт не прогадаешь, а recv возвратит сколько рельно прочитано.
[Net] А в чем проблема? 07.05.02 11:55  
Автор: xgiroo Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Если в сокет (IPPROTO_TCP) пришло, например, 50 байтов, а я
> в обработчике сообщения FD_READ даю команду recv (или
> WSARecv) с размером буфера 20 байтов, то сначала
> возвращаются последние 10 байтов сообщения, вновь возникает
> событие FD_READ, последующая команда recv возвращает байты
> 20-39, в следующий раз возвращаются первые 20 байтов. В чем
> проблема? Или так и должно быть? Как тогда правильно
> обрабатывать данные, я же не могу предугадать размер
> поступивших данных? На codeguru посоветовали использовать
> модель select, но меня устраивает именно асинхронная модель
> WSAAsyncSelect, все равно алгоритм на интерфейс завязан.

А в чем проблема? Не используй WSAAsyncSelect, используй либо
просто WSARecv, либо создавай новую нить и в ней можно пускать recv,
данные будут приниматься нормально.
[Net] Это понятно, спасибо, ... но не об этом ведь спросил 07.05.02 15:08  
Автор: mijk Статус: Незарегистрированный пользователь
<"чистая" ссылка>
WSAAsyncSelect вообще неработоспособна, что ли? Кто-нибудь вообще использовал?!! Просто программа получается очень простой на этой модели, не нужно синхронизации потоков... :(
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2025 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach