| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Асинхронные сокеты "забивают" очередь сообщений
SpellCaster © (2008-04-01 17:01:00)Делаю класс асинхронного сокета и столкнулся с проблемкой зависания проги. Прога коннектится к серверу и начинает принимать от него непрерывный поток данных. Соответственно, после каждого Recv в очередь сразу же ставится следующее сообщение с событием FD_READ, которое тут же и обрабатывается. В итоге сообщения от главного окна просто не могут пробиться сквозь этот цикл. Вместе с тем, если запускать в начале процедуры SocketEvent Application.ProcessMessages, то все работает (естественно). Однако есть у меня сомнение: ведь эта процедура сразу вытаскивает из очереди очередное сообщение. Вполне вероятно, что это может оказаться следующая мессага от того же сокета - и тогда SocketEvent будет запущен второй раз, а уже после обработки этого сообщения управление вернется к первой копии SocketEvent. То есть, к примеру, может получиться так, что сначала обработается FD_CLOSE, а потом придет очередь FD_READ, что не очень-то здорово.
Поэтому хочу спросить у знатоков, есть ли какой-то хороший путь решения данной проблемы? Или, может, я зря волнуюсь насчет перепутывания сообщений? В идеале хотелось бы иметь способ вместо ProcessMessages обработать только мессаги формы, а потом уже с чистой совестью заниматься с сокетом.
Посмотрел сорсы ICS, там реализована собственная выборка собщений. В принципе, можно сделать так же, но я пока не разобрался, как ее применять.
В общем, если что посоветуете, буду рад... только два условия:
1) Не хочется юзать нити
2) Видеть реплики типа "Зачем тебе это надо" и "не занимайся ерундой" также не горю желанием.
SpellCaster (2008-04-04 17:31:00) [21]> Событие готовности гнезда к чтению предполагает чтение из
> гнезда, а не выкрутасы с польз.интерфейсом !
А я что, спорю? Предложи альтернативный способ, я его с радостью рассмотрю.
> Ну и что ? Первая же попытка чтения вернет отказ, на который
> твой обработчик должен адекватно отреагировать.
Да, но пришедшие данные будут утеряны!
Сергей М. (2008-04-04 14:30:00) [22]
> если я вызову Application.ProcessMessages в начале обработчика
> FD_READ
Событие готовности гнезда к чтению предполагает чтениеиз гнезда, а не выкрутасы с польз.интерфейсом !
> FD_CLOSE, который спокойно закроет сокет и вернет управление
> обработчику FD_READ, который будет безуспешно пытаться прочитать
> данные из закрытого сокета
Ну и что ? Первая же попытка чтения вернет отказ, на который твой обработчик должен адекватно отреагировать.
SpellCaster (2008-04-04 13:53:00) [23]> [19] Сергей М. © (03.04.08 16:33)
> Ты о чем - о SOCKS4, о SOCKS5 ?
Говорил же...
>Прокси-сервер, работающий по протоколу Socks5.
Обычный метод, без аутентификации.
> Ты бросил огрызок код - нате, мол, догадывайтесь сами о
> том что я не изволил привести и не собираюсь приводить.
>
> Ну и какого ответа ты после этого ждешь ?
"Отгрыз" я код по единственной причине - чтобы не загружать приведенный фрагмент лишними строками, где не происходит ничего важного, кроме заполнения полей записи. Не думаю, что кто-то захочет ковыряться в длинном листинге.
К тому же позволю себе заметить, что данная процедура весьма слабо соотносилась с сабжем.
> для чего нужно всего лишь на время "переговоров" с прокси
> перевести гнездо в блок.режим
Хм, это, конечно, вариант... однако прога на время установки соединения будет блокироваться, чего бы не хотелось. Можно еще с неблокирующими сделать, в цикле проверять готовность и периодически вызывать ProcessMessages. Но мне это кажется слегка нелогичным.
> Если я правильно понял, ты сочиняешь некий "упрощенный"
> TClientSocket, способный работать с сервером через некий
> socks-прокси в "прозрачном" режиме ?
В целом, верно.
> Откуда ей, этой "мессаге от того же сокета" взяться, если
> recv() ты вызываешь после Application.ProcessMessages ?
Воот, наконец-то вернулись к сути вопроса. Разумеется, я не имел в виду FD_READ. Но ведь событие может быть и другим, например, FD_CLOSE. Тогда-то и случится засада: если я вызову Application.ProcessMessages в начале обработчика FD_READ, будет вызван обработчик FD_CLOSE, который спокойно закроет сокет и вернет управление обработчику FD_READ, который будет безуспешно пытаться прочитать данные из закрытого сокета. Так ведь получается?
> Равно как и очередной вызов send() следует выполнять не
> раньше FD_WRITE-события, если оно явилось следствием отказа
> WSAEWOULDBLOCK при предыдущем вызове send()
Учту...
Сергей М. (2008-04-03 17:20:00) [24]
> Вполне вероятно, что это может оказаться следующая мессага
> от того же сокета - и тогда SocketEvent будет запущен второй
> раз
Откуда ей, этой "мессаге от того же сокета" взяться, если recv() ты вызываешь послеApplication.ProcessMessages ?
Очередное FD_READ-событие возникнет не раньше чем будет выполнен вызов recv().
Равно как и очередной вызов send() следует выполнять не раньше FD_WRITE-события, если оно явилось следствием отказа WSAEWOULDBLOCK при предыдущем вызове send()
Сергей М. (2008-04-03 17:07:00) [25]Если я правильно понял, ты сочиняешь некий "упрощенный" TClientSocket, способный работать с сервером через некий socks-прокси в "прозрачном" режиме ?
Сергей М. (2008-04-03 16:33:00) [26]
> во время установки связи через соксы
Какие "соксы" ?
Ты о чем - о SOCKS4, о SOCKS5 ?
Там кучарежимов, вплоть до необходимости реконнекта кл.гнезда по указанному сервером адресу !
Почем мне знать, какой протокол в каком режиме ты решил использовать ?
Ты бросил огрызок код - нате, мол, догадывайтесь сами о том что я не изволил привести и не собираюсь приводить.
Ну и какого ответа ты после этого ждешь ?
> я ОЧЕНЬ сильно сомневаюсь в вероятности
Не надо сомневаться. Не сильно ни слабо. Надо действовать в точном соответствии с логикой Winsock, а не надеяться на авось.
И уж если тебе приспичило запихнуть в один флакон все это, то проще, надежней и очевидней бфло бы вынести handshake-логику в отдельную процедуру, никак не связанную ни с какими событиями гнезда, для чего нужно всего лишь на время "переговоров" с прокси перевести гнездо в блок.режим.
SpellCaster (2008-04-03 16:07:00) [27]> то ли буфер передачи освободился, то ли буфер приема не пуст
> Что за откровение такое тебе пришло, что это событие никогда
> у тебя не возникнет
Учитывая, что эта процедура выполняется сразу после создания сокета, а пересылаемые данные не превышают 100 байт, я ОЧЕНЬ сильно сомневаюсь в вероятности возникновения FD_WRITE как результата освобождения занятого буфера.
Имеется в виду, во время установки связи через соксы. Потом - вполне возможно, но я его и пересылаю в обработчик.
Пожалуйста, не надо давить на меня интеллектом. Я и так знаю, что ты гуру. А вот начальный вопростак и остается без ответа.
Сергей М. (2008-04-03 15:18:00) [28]
> она есть, даже если ты ее не видишь
Я даже по огрызкам вижу, что первым делом при входе в HandleSocksConnect ты тут же озабочен каким-то там fSocksState, хотя первым деломдолжен идти анализ причин возникновения события - то ли буфер передачи освободился, то ли буфер приема не пуст.
> второй вариант не рассматривается
Почему ? Что за откровение такое тебе пришло, что это событие никогда у тебя не возникнет ?
SpellCaster (2008-04-03 15:08:00) [29]> [15] Сергей М. © (02.04.08 21:10)
> Короче, сказ про то как "у попа была собака")
Для этого как раз и используется переменная fSocksState, которая отслеживает текущее состояние соединения с проксей. Никакого сказа про попа нету, иначе сокет никогда бы не сумел нормально добраться до удалённого хоста, а крутился бы в локалке.
> Кстати, где обработка FD_WRITE ?
> Только не говори, что она не нужна или ты не знаешь зачем
> она нужна)
Событие FD_WRITE возникает в двух случаях: после FD_CONNECT и когда предыдущий вызов Send закончился ошибкой по причине переполнения выходного буфера. В нашем случае второй вариант не рассматривается. А обработка - она как суслик: она есть, даже если ты ее не видишь ;)
> [2] SpellCaster (01.04.08 17:33)
FD_READ, FD_WRITE : if HandleSocksConnect then Exit;
Так, это все конечно интересно, но есть ли что сказать по существу вопроса?
Сергей М. (2008-04-02 21:10:00) [30]
> что тебя смутило, разве я как-то не так их использую?
Так ведь все эти твои send/recv, относящиеся к какому-то там "прокси", точно так же являются инициаторами потенциальных событий FD_READ и FD_WRITE, обрабатывая которые ты вновь вызываешь эту самую HandleSocksConnect, в которой ты опять вызываешь send/recv, относящиеся к какому-то там "прокси", которые являются инициаторами потенциальных событий FD_READ и FD_WRITE, которые ..
Короче, сказ про то как "у попа была собака")
Кстати, гдеобработка FD_WRITE ?
Нет ее !
Только не говори, что она не нужна или ты не знаешь зачем она нужна)
SpellCaster (2008-04-02 19:46:00) [31]> Какой режим гнезда они используют ?
Они не меняют режима, т.е. в данном случае в асинхронном. Считай, что это обычные вызовы send/recv winsock-a. А что тебя смутило, разве я как-то не так их использую?
Сергей М. (2008-04-02 17:34:00) [32]Какой режим гнездаони используют ?
Они чтго, на время выполнения переводят гнездо в блок.режим ?
Или обращаются совсем к другому
гнезду, нежели то самое неблокирующее гнездо, вокруг которого ты затеял сыр-бор ?
SpellCaster (2008-04-02 16:51:00) [33]Да, это методы класса, но они по большому счету просто вызывают винсоковские функции, плюс считают трафик и производят проверку активности сокета.
Сергей М. (2008-04-02 14:38:00) [34]Send и Recv - это методы класса TFrostAsyncClientSocket ?
Какой режим гнезда они используют ?
SpellCaster (2008-04-02 14:15:00) [35]Прости, но эти важныемоменты, на мой взгляд, не имеют никакого отношения к проблеме. Соединение через сокс проходит нормально. Разъясни, как это влияет на ответ по сабжу, может, я чего-то недопонимаю...
// Connect to Socks
function TFrostAsyncClientSocket.HandleSocksConnect: Boolean;
var len: Integer;
auth: TSocks5AuthSel;
ameth: TSocks5AuthMeth;
req: TSocks5Request;
repl: TSocks5Reply;
Addr: array[0..255] of Byte;
begin
Result:=True;
if fProxyUsed and (fSocksState in [ssConnecting..ssRequesting]) then
case fSocksState of
ssConnecting: // Договариваемся о методах аутентификации
begin
fSocksState:=ssMethSelecting;
...
Send(@auth,3,True);
end;
ssMethSelecting: // Устанавливаем связь с хостом
begin
if Recv(@ameth,SizeOf(ameth))<=0 then begin Close; WSASetLastError(WSAESOCKSCONNECT); Exit; end;
...
fSocksState:=ssRequesting;
Send(@req,SizeOf(req));
Send(@Addr[0],len,True);
end;
ssRequesting: // теперь читаем ответ - ровно столько, сколько прислали
begin
// сначала читаем версию, ответ, резерв, тип адреса и 1 байт адреса
len:=Recv(@repl,SizeOf(repl));
...
if Recv(@Addr,len-1+2)<=0 then begin Close; WSASetLastError(WSAESOCKSCONNECT); Exit; end;
...
fSocksState:=ssEstablished;
fActive:=True;
if Assigned(OnEvent) then OnEvent(Self,fSckt,FD_CONNECT);
PostMessage(fHwnd,WM_SOCKMSG,fSckt,MakeLong(FD_WRITE,0));
end;
end // case
else Result:=False;
end;
Я убрал заполнение свойств структур, чтобы не очень много получилось. Основнй смысл в том, что метод что-то делает только тогда, когда стоит признак использования прокси и состояние коннекта к сокс-серверу не равно ssEstablished.
Сергей М. (2008-04-02 13:52:00) [36]
> закончим оффтоп и вернемся к обработке сообщений?
>
Это далеко не оффтоп.
Но если тебе по барабану все эти важныемоменты, то показывай, что у тебя творится в теле HandleSocksConnect
SpellCaster (2008-04-02 13:44:00) [37]> [7] Сергей М. © (02.04.08 13:18)
Ну вот, снова началось...
Прокси-сервер, работающий по протоколу Socks5.
По спецификациям протокола.
Получать и отправлять данные в асинхронном режиме.
Не знаю, как ты определяешь транспортный или прикладной класс. Однако я сделал так, как сделал. Причем в обоих паках инет-компонентов, что я глядел, соксы упрятаны на самый низкий уровень. Ибо нет смысла вытаскивать их выше.
А теперь, может, закончим оффтоп и вернемся к обработке сообщений?
Сергей М. (2008-04-02 13:18:00) [38]
> Устанавливается коннект с проксей
Кто такая "прокся" ?
Как устанавливается коннект с ней ?
Каково вообще назначение класса TAsyncClientSocket ?
Это чистой воды транспортный класс ?
Если да, то какого лешего он лезет в прикладной протокол ?
SpellCaster (2008-04-02 13:03:00) [39]> [5] Григорьев Антон © (02.04.08 12:54)
Вот такая процедурка, одна на всех
function InnerWndProc(wnd: hWnd; msg, wParam, lParam: Longint): Longint; stdcall;
var sock: TObject;
s: string;
begin
if not ((msg = WM_SOCKMSG) or (msg = WM_TIMER)) then
begin
Result:=DefWindowProc(wnd,msg,wparam,lparam);
Exit;
end;
// else
Result:=0;
sock:=TObject(Pointer(GetWindowLong(wnd,GWL_USERDATA)));
if sock=nil then Exit;
s:=sock.ClassName;
if s='TAsyncClientSocket' then
case msg of
WM_SOCKMSG: TAsyncClientSocket(sock).DoEvent(WParam, LParam);
WM_TIMER: TAsyncClientSocket(sock).DoTimer;
end
else
if s='TAsyncServerSocket' then
case msg of
WM_SOCKMSG: TAsyncServerSocket(sock).DoEvent(WParam, LParam);
WM_TIMER: TAsyncServerSocket(sock).DoTimer;
end;
end;
Окошко у каждого сокета своё, внутреннее.
P.S. Огромное спасибо за статью на Королевстве. Я именно по ней изучал сокеты :)
Григорьев Антон (2008-04-02 12:54:00) [40]А как огранизован приём сообщений классом TAsyncClientSocket? Какое окно за это отвечает? Кто вызывает TAsyncClientSocket.DoEvent?
| |
Страницы: 