TspClient и TspServever

← →
kostyl_kostyl (2009-08-12 15:37) [40]

> Peek at the incoming data. The data is copied into the buffer but is not removed from the input queue

← →
Dennis I. Komarov © (2009-08-12 15:42) [41]

"Ну и что это за народное творчество..." (С) Матроскин

← →
kostyl_kostyl (2009-08-12 15:51) [42]

так к чему мы пришли? я не понял...

← →
Dennis I. Komarov © (2009-08-12 15:52) [43]

к [38]...

← →
kostyl_kostyl (2009-08-12 15:56) [44]

ой, могли бы и сказать, а то ломаетесь тут... А вообще спасибо всем кто помогал.

← →
Сергей М. © (2009-08-12 16:01) [45]

> kostyl_kostyl (12.08.09 15:37) [40]

Это откуда такое взялось ?

Цитирую фрагмент справки к методу TBaseSocket.ReceiveLn :

Reads delimited lines of data from the socket.

..
Description

Receiveln reads a delimited chunk of data from the socket. The delimeter cannot be part of the character set. Receiveln fills the buffer until it reaches the delimeter.

← →
Dennis I. Komarov © (2009-08-12 16:02) [46]

> могли бы и сказать, а то ломаетесь тут...

Это лишено смысла...

← →
Сергей М. © (2009-08-12 16:04) [47]

> а то ломаетесь тут

Ну зато ты, видимо, тверже дуба - не cломаешься своей головой подумать и выяснить)

← →
kostyl_kostyl (2009-08-12 16:05) [48]

> Сергей М. © (12.08.09 16:01) [45]

Я просто глубже полез...

Кстати, а если у меня сервер очень долго обрабатывает сообщение, он будет все это время "держать" клиента?

← →
Сергей М. © (2009-08-12 16:20) [49]

> Я просто глубже полез

"Глубже" - это куда ?

> если у меня сервер очень долго обрабатывает сообщение, он
> будет все это время "держать" клиента?

Что значит "держать" ?
Клиент волен в любое время по своему желанию "уйти")

← →
Dennis I. Komarov © (2009-08-12 16:27) [50]

> "Глубже" - это куда ?

В процессор...

← →
kostyl_kostyl (2009-08-12 16:27) [51]

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

← →
Dennis I. Komarov © (2009-08-12 16:30) [52]

> хочет его получить в течение 10 минут не более

тогда ждать 10 и потом "уходить"...

> при этом для пользователя клиента это все должно быть прозрачно.

Это как? И он то как тут оказался?

← →
kostyl_kostyl (2009-08-12 16:31) [53]

> Dennis I. Komarov © (12.08.09 16:27) [50]

recv(FSocket, buf, bufsize, MSG_PEEK)

← →
kostyl_kostyl (2009-08-12 16:32) [54]

> Это как?

Ну пользователь же ждет пока приложение получит ответ.

← →
Dennis I. Komarov © (2009-08-12 16:34) [55]

> kostyl_kostyl (12.08.09 16:31) [53]

Что-то я не видел этого в твоем коде... А вообще генофонд большой, давай еще "глубже"

← →
Dennis I. Komarov © (2009-08-12 16:37) [56]

> Ну пользователь же ждет пока приложение получит ответ.

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

← →
Сергей М. © (2009-08-12 16:44) [57]

> Ка должен вести себя клиент если от послал запрос и хочет
> его получить в течение 10 минут не более

Он должен запустить тем или иным образом какой-либо 10-минутный таймер, по срабатыванию которого волен закрыть соединение по своей инициативе.

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

Что значит "прозрачно" ?

> пользователь же ждет пока приложение получит ответ

Если ему больше нечем заняться, то да - пусть себе ждет.
Разве в этом есть нечто непотребное ?

← →
Anatoly Podgoretsky © (2009-08-12 16:45) [58]

> kostyl_kostyl (12.08.2009 16:32:54) [54]

Ну это дело клиента ждать или нет.

← →
kostyl_kostyl (2009-08-12 16:58) [59]

> рабатыванию которого волен закрыть соединение по своей инициативе.

Так ему надо делать попытки чтения все 10 минут правильно?

> я не видел этого в твоем коде

а это не в моем коде...

← →
Dennis I. Komarov © (2009-08-12 17:08) [60]

> Так ему надо делать попытки чтения все 10 минут правильно?

Да тех пор, пока не прочитает то что нужно или не отвалится по таймауту

> а это не в моем коде...

И какого оно тут оказалось тогда? Телепаторы тестируешь?

← →
Сергей М. © (2009-08-12 17:10) [61]

> ему надо делать попытки чтения все 10 минут правильно?

Все зависит от режима BlockMode

← →
kostyl_kostyl (2009-08-12 17:15) [62]

> Dennis I. Komarov © (12.08.09 17:08) [60]

function TBaseSocket.PeekBuf(var Buf; BufSize: Integer): Integer; begin Result := ErrorCheck(recv(FSocket, buf, bufsize, MSG_PEEK)); end;

> Все зависит от режима BlockMode

Как зависит?

← →
Сергей М. © (2009-08-12 17:19) [63]

> Как зависит?

Алгоритмы "ожидания" и "попыток" существенно отличаются.
При bmNonBloking логика одна, а при bmBlocking иная.
Но ты до сих пор не сподобился уточнить используемый тобой режим, а это весьма важно, если хочешь дальнейшего детального обсуждения.

← →
Dennis I. Komarov © (2009-08-12 17:23) [64]

> не сподобился уточнить используемый тобой режим

Как он его выберет, если он не знает разницу?

> kostyl_kostyl (12.08.09 17:15) [62]

А чего не весь модуль то? Чего ты этим хочешь сказать? Зачем ты приводишь сдесь функции, которые ты не используешь?

← →
kostyl_kostyl (2009-08-12 17:25) [65]

Дело в том что я и не знаю какой мне использовать. Я хочу отправить запрос и получить ответ тут же, потому что приложению для дальнейшей работы надо знать результат. Но сервер довольно долго обрабатывает запрос. Вот я из этого и исхожу.

← →
Dennis I. Komarov © (2009-08-12 17:28) [66]

> kostyl_kostyl (12.08.09 17:25) [65]

Самому не смешно?

← →
Сергей М. © (2009-08-12 17:31) [67]

> не знаю какой мне использовать

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

Остановись пока на каком-либо одном и будем его рассматривать в лупу.

По умолчанию, если мне не изменяет память, устанавливается режим bmMonBlocking.

← →
kostyl_kostyl (2009-08-12 17:36) [68]

ну у меня сейчас установлен на клиенти bmBlocking, а не сервере bmThreadBlocking

← →
kostyl_kostyl (2009-08-12 17:54) [70]

Задача озвучена в:

> kostyl_kostyl (12.08.09 17:25) [65]

или надо еще подробнее?

Ты его сам то читал?

← →
kostyl_kostyl (2009-08-12 18:05) [72]

> Ты его сам то читал?

Я вас не пойму, что вы хотите услышать от человека, который не знает механизма работы?

> Я хочу отправить запрос и получить ответ тут же, потому
> что приложению для дальнейшей работы надо знать результат.
> Но сервер довольно долго обрабатывает запрос.

Какой ты хочешь "тут же" получить ответ от сервера, если он будет готов через "довольно долго"?

Или совсем клиника, или я не знаю что это...

← →
kostyl_kostyl (2009-08-12 18:10) [74]

Это идеальный вариант. Дело в том что я не знаю как не заставлять приложение ждать ответа и выполнять другие функции.

А [24] для кого написано? Для Гоголя?

← →
kostyl_kostyl (2009-08-12 18:33) [76]

Постараюсь лучше объяснить:
Вот у меня код обработки ответа:
1. TcpClient.SendBuf(ClientRequest, 13); 2. TcpClient.ReceiveBuf(ServerResponse, 268); 3. TcpClient.Disconnect; 4. ProcessServerResponse(ServerResponse);
Меня смущает что строки 1 и 2 выполняться в один момент и вижу два бока, когда либо клиент зависнет на строке 2 либо в строке 4 ServerResponse будет неверная информация, потому что сервер долго обрабатывает запрос.

← →
kostyl_kostyl (2009-08-12 20:02) [77]

Я не знаю как будет на самом деле, но знаю что сервер точно сформирует ответ. А вот когда это будет я без понятия, возможно я уже отконнекчусь и он не успеет передать данные. Значит мне надо подождать пока он это сделает, но вот ждать я не могу. Что делать? Может сделать обработку ответа в отдельном потоке, а по приходу ответа изменить какую то глобальную переменную и запусить ProcessServerResponse(ServerResponse)?

А ты вообще в курсе, какой кодовый поток процесса твоего приложения ответственен за GUI ?

← →
kostyl_kostyl (2009-08-12 22:17) [79]

Если честно не в курсе

В VCL-приложении - основной.
И он же, основной поток, у тебя вызывает метод ReceiveLn.
Пока метод не завершит выполнение, осн.поток не будет исполнять свои GUI-обязанности, что и создает иллюзию "подвисания".
Отсюда напрашивается решение: либо переносить работу с TTCPClient в доп.поток (он так же будет "зависать" на время вызова метода, но это не повлияет на работу осн.потока, ибо потоки исполняются "параллельно") либо переводить TTCPClient в режим bmNonBlocking, оставив работу с ним в осн.потоке.

TspClient и TspServever Найти похожие ветки