Если я правильно понял, ты сочиняешь некий "упрощенный" TClientSocket, способный работать с сервером через некий socks-прокси в "прозрачном" режиме ?

> Вполне вероятно, что это может оказаться следующая мессага
> от того же сокета - и тогда SocketEvent будет запущен второй
> раз


Откуда ей, этой "мессаге от того же сокета" взяться, если recv() ты вызываешь после Application.ProcessMessages ?

Очередное FD_READ-событие возникнет не раньше чем будет выполнен вызов recv().

Равно как и очередной вызов send() следует выполнять не раньше FD_WRITE-события, если оно явилось следствием отказа WSAEWOULDBLOCK при предыдущем вызове send()

> [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()

Учту...

> если я вызову Application.ProcessMessages в начале обработчика
> FD_READ


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


> FD_CLOSE, который спокойно закроет сокет и вернет управление
> обработчику FD_READ, который будет безуспешно пытаться прочитать
> данные из закрытого сокета


Ну и что ? Первая же попытка чтения вернет отказ, на который твой обработчик должен адекватно отреагировать.

> Событие готовности гнезда к чтению предполагает чтение из
> гнезда, а не выкрутасы с польз.интерфейсом !

А я что, спорю? Предложи альтернативный способ, я его с радостью рассмотрю.

> Ну и что ? Первая же попытка чтения вернет отказ, на который
> твой обработчик должен адекватно отреагировать.

Да, но пришедшие данные будут утеряны!

> Предложи альтернативный способ, я его с радостью рассмотрю


Альтернатив нет - сначала recv(), а потом выкрутасы.

Не нравится ?

Выноси транспорт с его событиями в доп.поток.


> пришедшие данные будут утеряны


С чего ты так уверен ?

> С чего ты так уверен ?

Из закрытого сокета вроде как читать не получится...
Хорошо, тогда будет 2 вопроса:
1) Как организовать обработку событий сокета в отдельном потоке, потому что мессаги все равно ведь приходят в Application. Возможно, их надо фильтровать по коду мессаги?

2) Как насчет варианта вместо ProcessMessages сделать свой аналог, который будет извлекать из очереди только сообщения, не относящиеся к сокетам.

> Из закрытого сокета вроде как читать не получится


Чтение-то не из сокета происходит, а из внутреннего буфера приема !

Если там что-то имеется на момент закрытия сокета, то recv вернет это самое "что-то".


> 1)


Ты обработку с выборкой не путаешь ?


> 2)


Никак.
Да и нафих оно не нужно, потому что извращенная это логика.

Но если изврат твоя стихия, то можно извлекать из очереди сообщения, относящиеся только к твоим сокетам и тут же ставить их в хвост очереди сообщений безо всякой обработки.

> Чтение-то не из сокета происходит, а из внутреннего буфера
> приема !
> Если там что-то имеется на момент закрытия сокета, то recv
> вернет это самое "что-то".

Ну да. Но разве он не освобождается после закрытия? К тому же хэндл уэ точно не будет иметь смысла после Close.

> Ты обработку с выборкой не путаешь ?

Угу... есть такое дело. Так как сделать это в отдельном потоке? Или там нужно будет PostThreadMessage юзать?

> разве он не освобождается после закрытия?


Смотря с какой стороны его закрыть.


> как сделать это в отдельном потоке?


Сделать что ?
Выборку ?
Обработку ?
И то и другое ?

Выборку

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

Ну и...?

Что "ну и" ?

В каком смысле > созданы в его собственном контексте.? Функция CreateЦindow была вызвана внутри Execute?
И тогда если в том же Execute я организую выборку сообщений, то она будет распространяться только на эти окна?

Хотя мне все равно кажется, что это не выход... блин, ну как-то же делают серваки с сотнями клиентов, которые не тормозят... и этот ICS все хвалили, а там ведь такая же система

> ну как-то же делают серваки с сотнями клиентов, которые
> не тормозят

Без окон


> и этот ICS все хвалили

ай да, конечно.

> В каком смысле > созданы в его собственном контексте.? Функция
> CreateЦindow была вызвана внутри Execute?


Да.
Хотя каким боком к тебе этот Execute ?
Ты вон все апями озабочен да BeginThread'ами)


> если в том же Execute я организую выборку сообщений, то
> она будет распространяться только на эти окна?


По умолчанию - да.


> как-то же делают серваки с сотнями клиентов, которые
> не тормозят


Их по-другому делают.
Ты же не озаботился исследованием, ты сразу ринулся код лепить)
Еще и оффтопом меня попрекнул)

Чудо, блин)

> Без окон

Может, есть и без окон, но большинтсво все-таки с гуем... виндоус все-таки. Ладно, уйдём от серваков. Возьмем "качалки" с кучей потоков загрузки - они-то не тормозят...

> Ты вон все апями озабочен да BeginThread'ами)

Вот не надо, треды через апи меня пока не привлекают)

> Ты же не озаботился исследованием, ты сразу ринулся код
> лепить)
> Еще и оффтопом меня попрекнул)

Гм. Исследованием чего?
Ну а насчет оффа - все-таки речь не о соксах, согласись.

> Их по-другому делают

Вот я и хочу узнать, какой там принцип юзается. С нитями понятно, хотя все равно не хочется с ними дело иметь - иначе смысл городить огород, легче все на синхронных оставить...