| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Посоветуйте с выбором компонента для работы с TCP
Piter © (2004-08-12 00:59:00)Пробовал и не надо предлагать TTcpClient.
Также не предлагайте пока самому работать с WinApi напрямую.
Сейчас перешел на TIdTCPClient - вроде ничего, но есть маленькая проблема... Вообще, хотелось бы спросить - у компонентов, которые работают в блокирующем режиме логика должна быть такова - подсоединяешься, вызываешь Recv (ReceiveBuf или как там этот метод у комонента называется), если он вернул ноль байт - это означает, что соединение разорвано, верно?
Если верно, то проблема в том, что бывает Recv долго не отдает управление, причем все данные уже переданы. В конце концов, после 30 секунд ожидания управление возвращается и оказывается, что получено ноль байт.
То ли это особенность TIdTCPClient, то ли это глюк сервера (после передачи всех данных он не рвет соединение) - никак не пойму. Стоит сказать, что работаю я с протоколом HTTP и тот же запрос IE почему-то отрабатывает быстро без всякого ожидания. То ли... я вот сейчас подумал, может TIdTCPClient вовсе и не в блокирующем режиме работает? По всем признакам похоже на блокирующий режим, но может я чего не знаю...
Вот я так сумбурно все описываю, но это потому что я вижу следствие, а причин не знаю.
Вот можно сформулировать несколько подвопросов, которые и составляют мой больщой вопрос:
1) TIdTCPClient работает в блокирующем режиме?
2) Если компонент в блокирующем режиме при вызове Recv возвращает ноль - это означает, что соединение разорвано?
3) кто при HTTP соединении должен разорвать соединение, сервер? И есть ли какие-то признаки для клиента, что соединение можно разорвать
Ну и последнее - посоветуйте компонент, который корректно работает в блокирующем режиме. Только не приводите все компоненты, которые знаете. Хочется спросить людей, которые хотя бы год работают с компонентом и не выявили в нем никаких изъянов. Компонент должен уметь работать в блокирующем режиме, то есть на каждое соединение программа создает новый поток, в новом потоке создается экземпляр данного компонента и идет работа.
Digitman (2004-08-16 16:46:00) [21]
> Piter © (13.08.04 22:57) [9]
> в чем выражается гибкость и эффективность?
потому что это чистой воды транспорт.
практически безо всяких прикладных "нахлобучек" поверх негохош синхронный, а хош асинхронный - выбирай на вкус
> чем Indy уступает?
как правило масса лишнего-ненужного
и выбора нет - транспорт только синхронный
Piter (2004-08-13 22:57:00) [22]Digitman © (13.08.04 14:11) [6]
по тому же TCP работает и старая борландовская "связка" - TServer/ClientSocket, которая "заточена" именно под Win и потому дает ощутимую эффективность и гибкость в использовании
а в чем выражается гибкость и эффективность? В чем недостаток Indy в этом аспекте?
Кросс-платорменность вовсе не нужны. И хочется задать вопрос - чем Indy уступает? Скорость, размер кода, требования к ресурсам?
nikkie © (13.08.04 17:08) [7]
унаследован от TIdTCPConnection.
сории, это меня уже колбасит
alienserg (2004-08-13 22:31:00) [23]Piter © (13.08.04 01:42) [4]
а разве не верно, что если ничего не пришло - значит коннект разорван? Иначе как определить разрыв соединения?
Не-а, неверно. Надо специально делать Disconnect или на сервере или на клиенте, чтобы разорвать соединение.
Для того, чтобы определить непредвиденный разрыв соединения, надо регулярно слать на сервер короткие keep-alive сообщения. Если операция записи в сокет выдала ошибку, то значит коннект разорвался. А на сервере регулярно проверяй, когда в последний раз юзер проявлял признаки жизни. Если молчание затянулось, то это значит, что коннект непредвиденно разорвался.
Все таки жду советов по выбору TCP компонента.
Вот я тебе и советую использовать Indy :) Один из самых сильных доводов в пользу Indy это очень качественная поддержка в ньюсгруппах. Советую полазить по ним.
Digitman © (13.08.04 14:11) [6]
если планируется работа только под Win, то Инди далеко не панацея...
А какие явные изъяны Indy под Win ты видишь? Отсутствие асинхронного режима?
nikkie (2004-08-13 17:08:00) [24]>а где у TidTCPClient есть метод ReadLn?!
унаследован от TIdTCPConnection.
Digitman (2004-08-13 14:11:00) [25]
> жду советов по выбору TCP компонента
если планируется мультиплатформенность приложения, то Инди подойдет
если планируется работа только под Win, то Инди далеко не панацея ... по тому же TCP работает и старая борландовская "связка" - TServer/ClientSocket, которая "заточена" именно под Win и потому дает ощутимую эффективность и гибкость в использовании - никаких излишеств, чистой воды транспорт, безо всяхих бестолковых "наворотов" поверх него, на выбор два режима - блокирующий синхронный и неблокирующий асинхронный с использованием механизма оконных нотификаций
Piter (2004-08-13 13:28:00) [26]nikkie © (12.08.04 2:05) [2]
а если хочется сам http реализовывать, то удобно пользоваться методом Readln, а не Recv
а где у TidTCPClient есть метод ReadLn?!
Piter (2004-08-13 01:42:00) [27]alienserg (12.08.04 4:01) [3]
Там считывание организовано через readln по таймеру.
если считаное - пусто, то ждем следующей строки
а разве не верно, что если ничего не пришло - значит коннект разорван? Иначе как определить разрыв соединения?
Все таки жду советов по выбору TCP компонента. Это и не только для клиентов, а вообще для всех моих сетевых приложений
alienserg (2004-08-12 04:01:00) [28]Piter © (12.08.04 00:59)
Компонент должен уметь работать в блокирующем режиме, то есть на каждое соединение программа создает новый поток, в новом потоке создается экземпляр данного компонента и идет работа.
Разве блокирующий режим каким либо образом обязывает программу создавать экземпляр компонента динамически и запускать его в отдельном потоке?
Если ты имеешь ввиду заморозку формы при выполнении операции в сокете в блокирующем режиме, то Indy предлагает другое решение этой проблемы. Надо сбросить _один_на_все_приложение_ компонент TIdAntiFreeze. И все. Формы замораживаться не будут во время работы TIdTcpClient.
С другой стороны никто не мешает создать экземпляр ручками и запустить его в отдельном потоке. Я так и делаю в некоторых случаях.
По поводу разрыва коннекта сразу после считывания... Разве это кто-то регламентирует для TCP? TIdTcpClient не обрывает в автомате коннект после считывания.
В демках Indy есть пример TCP Chat.
Там считывание организовано через readln по таймеру.
если считаное - пусто, то ждем следующей строки.
Если пришла строка, то анализируем ее.
Если понял, что пришло уже все, что надо, то тогда делай Disconnect.
Тут ранее критиковалось использование таймера для этого дела, но я минусов не вижу. Когда я получаю ответ, требующий длительной обработки, то отключаю на это время таймер.
С Indy работаю как раз около года и впечатления только положительные.
Просто с самого начала надо учесть несколько нюансов.
Из тредов рисовать на форме только через Synchronize/TIdSync/PostMessage
и не забывать про TIdAntiFreeze.
Если перед тобой стоит задача коннект - посылка команды - прием ответа - дисконнект, то может действительно стоит прислушаться к nikkie © (12.08.04 01:53) [1] а не мучаться на низовом уровне с TCP...
nikkie (2004-08-12 02:05:00) [29]а если хочется сам http реализовывать, то удобно пользоваться методом Readln, а не Recv.
nikkie (2004-08-12 01:53:00) [30]все упорствуешь, не хочешь готовой компонентой воспользоваться...
IdHTTP.Get и все проблемы решены. ну или почти все...
ЗЫ инди только в блокирующем режиме и работает. иначе не умеет.
| |
Страницы: 