TThread.Suspend и TWinSocketStream.TimeOut

← →
neteditor © (2004-06-02 20:31) [0]

Подскажите, как реагирует TWinSocketStream на Suspend "несущей" его нити? Одолевают смутные подозрения что не совсем так, как надо. И касается это, в основном подозрений насчет того, что отсылающая сторона тоже имеет таймауты. Просветите темного :)

← →
Digitman © (2004-06-03 08:22) [1]

никак не реагирует.

потому что как только "несущая" нить переходит в Suspend-состояние, ни одна ее маш.инструкция не выполняется процессором - ни инструкции в составе кода объекта WinSocketStream, ни какие бы то ни было иные

если нить отсылающей стороны не "спит" и послала что-то в этот момент (хоть с таймаутом, хоть без оного), то "спящее" состояние нити принимающей стороны на это до поры до времени никак не влияет - фактический прием данных на канальном уровне ведет не "спящая" нить (это прикладной уровень), а система, которая никогда не спит и которая принимает-накапливает вх.поток во внутренних буферах приема (общий размер которых, разумеется, ограничен)

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

← →
neteditor © (2004-06-04 13:27) [2]

Если я правильно понял, то таймаут TWinSocketStream не привязан к системному времени, а исключительно к времени выполнния кода самого объекта WinSocketStream?

Может, и не по теме, но все же

>... накапливает вх.поток во внутренних буферах приема (общий
> размер которых, разумеется, ограничен)...

Получается, что этот буфер общий для всех принимающих программ (поскольку он системный). И если я "усыплю" нить, принмающую побольше, то могу "убить" остальные принимающие программы?

Где можно узнать или изменить размер этого буфера, если это вообще возможно?

p.s. Огромное спасибо за ответ [1].

← →
Digitman © (2004-06-04 13:59) [3]

> Если я правильно понял, то таймаут TWinSocketStream не привязан
> к системному времени, а исключительно к времени выполнния
> кода самого объекта WinSocketStream?

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

> Получается, что этот буфер общий для всех принимающих программ
> (поскольку он системный).

нет, для каждой гнезда система создает отдельный буфер (точнее сказать - цепочку буферов, образующих кольцевую очередь ввода/вывода на канальном уровне)

> если я "усыплю" нить, принмающую побольше, то могу "убить"
> остальные принимающие программы?

нет, на иные программы это никак не повлияет

> Где можно узнать или изменить размер этого буфера, если
> это вообще возможно?

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

мне вообще непонятно, чем у тебя вызвана необходимость "усыпления" потока, поясни это ...

← →
neteditor © (2004-06-04 15:06) [4]

Связано это с ограничением пропускной способности в нашей сети.

А задача простая - нужно получить определенную информацию с разных серверов (причем их довольно много). При этом заранее неизвестен ни размер ответа ни время его поступления (сервер может ответить с задержкой в пределах до 10 сек).

Вот я и ищу выход. Ведь если ответит сразу несколько срверов - пропускной способности не хватит. Может, я не там ищу?

p.s. Прием по очереди отмели сразу, как не рациональное решение с точи зрения затрат времени

← →
Digitman © (2004-06-04 15:38) [5]

> Связано это с ограничением пропускной способности в нашей
> сети

не вижу никакой связи

поток вполне может не "спать" (находиться в kernel-time, например, вызывав одну из системных ф-ций ожидания сообщений/событий) и при этом, не отнимая процессорного времени, мгновенно реагировать на сигналы системы о каких-то событиях (в дан.случае, например, транспортных, т.е. событие поступления очер.порции данных от передающей стороны)

> При этом заранее неизвестен ни размер ответа ни время его
> поступления (сервер может ответить с задержкой в пределах
> до 10 сек).

ну с задержкой ответа - это понятно, даже при идеальной проп.способности делать ставку на фикс.время ответа нельзя

а вот с неизвестностью "размера ответа" - это что-то новенькое .. как же у тебя вообще общяются клиенты и серверы. если протокол инф.обмена между ними не оговаривает конкретный формат сообщений ? даже если предположить, что обмен предполагает передачу простых нуль-терминированых строк, то и в этом простом случае принимающая сторона считает, что сообщение принято целиком, когда принят нуль-терминатор..

> поток вполне может не "спать" (находиться в kernel-time,
> например, вызывав одну из системных ф-ций ожидания сообщений/событий)
> и при этом, не отнимая процессорного времени, мгновенно
> реагировать на сигналы системы о каких-то событиях (в дан.случае,
> например, транспортных, т.е. событие поступления очер.порции
> данных от передающей стороны)

Так и сделаю.

Не совсем точно выразил мысль по поводу размера. Он неизвестн ЗАРАНЕЕ. А в самой посылке он указывается.

Спасибо за ответы.

> Он неизвестн ЗАРАНЕЕ. А в самой посылке он указывается.

значит известен

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

когда размер префикса ЗАРАНЕЕ известен, все остальное - дело техники

TThread.Suspend и TWinSocketStream.TimeOut Найти похожие ветки