![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Проблемы при работе с Indy [D7, WinXP]
Cyrax © (2006-08-26 18:46:00)Столкнулся я с такой проблемой. При использовании компонента TIdTCPClient при отсоединении от сервера не освобождается порт, занимаемый клиентом. Отсоединяюсь я методом Disconnect (пробовал и DisconnectSocket). При каждом очередном соединении клиента ОС выделяет ему новый порт. Если же задать порт клиента самому, то при повторном соединении возникает ошибка - порт то остался занятым...
С TIdTCPServer такой проблемы не возникает.
Что самое интересное, пример работы с TIdTCPServer и TIdTCPClient (IdTCPDemo), скачанный с инета, показывает те же результаты.
На форумах читал, как обсуждали глюки некоторых компонентов Indy.
Так вот, может это очередной глюк? Или отсоединяться (клиенту) нужно как то по-другому?
Правильно ли я понимаю механизм соединения клиента с сервером:
При попытке клиента соединиться с сервером (метод TIdPeerThread.Run на клиенте) на стороне сервера вначале создаётся поток для обслуживания этого клиента. Далее происходит попытка установления связи с клиентом. Событие OnExecute на сервере генерится именно после создания потока. При этом возможна ситуация, когда поток создан, а соединение не установлено. При последующем успешном соединении этого же клиента используется тот же поток.
Если я в чём-то ошибаюсь, прошу меня поправить.
Остаётся непонятно, почему в начале обработчика события OnExecute нужно ставить проверку "if not AThread.Terminated". Что, OnExecute генерится ещё и при завершении работы потока?
Есть у меня и другая проблема. При создании объекта TIdTCPServer присвоил полям OnConnect и OnDisconnect имена обработчиков. Напомню, что я пишу модуль, и никакого интерфейса, а тем более визуальных компонентов, нет. Т.е. все объекты я создаю и инициализирую сам... Так вот, в процессе соединения и отсоединения клиентов сервер генерирует события OnConnect и OnDisconnect соответственно и вызывает мои обработчики этих событий (по крайней мере, должен). С коннектом проблем нет. НО: событие OnDisconnect на сервере не генерируется при отсоединении клиента. Это событие генерируется только при завершении работы сервера (IdTCPServer.Active := false). Как я понял из help'а, оно должно генерироваться при каждом отсоединении клиента. Именно так и происходит в случае с сервером и клиентом, созданных визуально путём установки на форму компонентов (в этом случае все необходимые поля инициализируются нужным образом).
Может я не все нужные поля у IdTCPServer проинициализировал?
Вот моя инициализация клиента:
MaxLineLength := DataMax;
MaxLineAction := maException;
ReadTimeout := 0;
BoundPort := 0; // чтобы не возникало проблем с занятым портом
Host := '127.0.0.1'; // пока для проверки
Port := 6002;
Инициализация сервера:
DefaultPort := port;
ThreadMgr := TIdThreadMgrDefault.Create(id_component);
MaxConnections := ClientsMax;
ListenQueue := 15;
OnExecute := onexecute;
OnConnect := onconnect; // мой обработчик
OnDisconnect := ondisconnect; // мой обработчик
_______________________
Дополнительные вопросы:
1. Как в винде посмотреть, какие порты в данный момент заняты и какими прогами (средствами винды, без программирования) + как принудительно освободить занятый порт (естественно, с завершением работы проги).
2. Свойство BoundIP клиента указывает IP компа, на котором можно его запускать ?
_______________________
Напоследок хочу узнать мнение тех, кто работал с Indy. Я пишу модуль, который будет обеспечивать связь клиентов с сервером по TCP/IP. Интерфейс представлен 4-мя функциями: инициализация, отправка, получение и завершение. Так вот, целесообразно ли использовать Indy для этих целей. Или проще напрямую работать с winsock, ведь Indy тоже работат через winsock.
Cyrax (2006-10-24 19:44:00) [1]Удалено модератором
Примечание: Повесит здесь, но закрытая и не вздумай восстанавливать, смотри правила.
Leonid Troyanovsky (2006-10-24 19:10:00) [2]
> Cyrax © (24.10.06 19:03) [154]
> Желательно перекинуть эту ветку назад, либо меня забаннить
> (только 2 варианта)...
В качестве третьего предлагаю и то и другое.
--
Regards, LVT.
Cyrax (2006-10-24 19:03:00) [3]Удалено модератором
Примечание: Обсуждение модерирования, а насчет угроз пока будут считать, что шутишь, но забанить всегда успеем
Anatoly Podgoretsky (2006-10-24 16:17:00) [4]
> в "начинающие" - в самый раз
Моя ошибка, исправлю
Сергей М. (2006-10-24 16:06:00) [5]
> если эта штука делается не по заказу, то сам понимаешь куда
> надо автора посылать?
Конечно понимаю)
Меня давно подмывает "послать" (в "начинающие" - в самый раз), хотя бы потому как автор изменил до неузнаваемости изначальный сабж.
Anatoly Podgoretsky (2006-10-24 16:00:00) [6]
> Я предлагаю автору представить заказчику подробное ТР
Это обязательно и если заказчик подпишет, то посылать лесом со всеми претензиями по безопасности, можно будет и отменить, но работу все равно оплатить и отдельно оплатить переделку, но я бы на месте заказчика серьезно задумался бы над подобным и послал бы автора по дальше и далее в соотвествии с договорами.
А если эта штука делается не по заказу, то сам понимаешь куда надо автора посылать?
Пока я не вижу ни одного разумного довода для подобной реализации.
Сергей М. (2006-10-24 15:15:00) [7]
> Предлагаешь убить?
Я предлагаю автору представить заказчику подробное ТР, чтобы специалисты заказчика сами могли сделать заключение, годится им это решение или не годится.
Anatoly Podgoretsky (2006-10-24 15:10:00) [8]
> Да мало ли какая гадость на компе заказчика может мешать
> работе твоего софта
Предлагаешь убить? Или все таки подчиняться корпоративным или другим правилам.
А то тут получается, какая то гадость постоянно сканирует сеть. Не так не живут в корпоративных сетях и убивается не на гадость которая мешает, а эта программа, как вредная для корпоративной сети, хорошо если автор выживет, а то улица широкая.
Сергей М. (2006-10-24 14:38:00) [9]
> Гляну. Если что - буду ругаться...
>
Только не говори потом, мол, искал и не нашел, потому что не туда, мол, смотрел)
Ты инженер или где ?)
> Блин, ушли хрен знает куда... рожать...
Эт точно)... Но я тебя, заметь, за язык не тянул - ты сам начал за здравие и ты сам же продолжил за упокой)
> как быть с диапазоном портов для UDP-сервера...
> Как вообще люди нормальный поиск сервера реализуют
Они его никак не реализуют.
Они , эти самые люди, говорят так: вот вам, к примеру, очередной шедевр в виде такого-то POP3-сервера, оной по таким-то известным соглашениям "сидит" на 110-м порту, а ежели у вас 110-й порт занят, то сервер можно посадить и на любой иной порт, но это уже ваши проблемы.
> С каким вопросом я должен обращаться к "специалистам по
> системному администрированию" - что-то вроде "Нужно как-
> то сделать что-то, чтобы антивирусники не ругались..." ?
>
Да какое тебе нафих дело до антивирусников и прочей не относящиейся к твоей компетенции софтовой тряхомудии ?)
Ты - разработчик, а не кто-то иной !
Да мало ли какая гадость на компе заказчика может мешать работе твоего софта ! В известный момент времени это его, заказчика, проблемы)
В ответ на ТЗ ты сотворил свое подробное ТР и отправил его на согласование представителю Заказчика. Заказчик же тебе, к примеру, вернул отлуп, мол, ТР не годится потому-то и потому-то. Далее ты волен отказаться от реализации проекта, потому как не знаешь иного решения, либо предложить это иное решение.
> Зато перебирать порты не придётся
Что тебя на портах заклинило ?)
Ты софт свой для ЛВС разрабатываешь или для глоб.сети ?
В ТЗ оговорена обязательная реализация трансп.подсистемы на базе IP или это твоя отсебячина ?
С чего ты взял, что в случае mailslots никаких "переборов" нет и в помине ?
"Ты суслика видишь ? И я не вижу. А он есть !" (С)
Anatoly Podgoretsky (2006-10-24 14:24:00) [10]Они тебе ответят, прекрати скан атаку, администрация тебя уже предупредила и это первый звонок. В локальной сети подобные штуки делать, это ужас, вместо использования не вирус подобных методов.
Cyrax (2006-10-24 13:24:00) [11]В справке есть все.
Гляну. Если что - буду ругаться...
Что значит "в общем-то" ?
Это, извини уж, похоже на "чуть-чуть беременна")
Сдается мне при этом, что ТЗ как такового не существует ..
Блин, ушли хрен знает куда... рожать...
Речь идёт о диапазоне адресов, с чего вопрос-то и начался. Ну так как быть с диапазоном портов для UDP-сервера...
Как вообще люди нормальный поиск сервера реализуют (самый распространённый вариант и чуть менее распространённые) ?
Делюсь - UDP быстр, но ненадежен, TCP надежен, но не быстр.
И это весь опыт-то ?
Профессионалу-сисадмину они д.б. известны.
И это вообще не твое (как разработчика) дело.
Твое дело - описать то что ты реализовал в ТР и представить его заказчику для согласования со специалистами по сет.администрированию.
Ну, допустим. С каким вопросом я должен обращаться к "специалистам по системному администрированию" - что-то вроде "Нужно как-то сделать что-то, чтобы антивирусники не ругались..." ?
Ну уж нет. Предпочитаю что-то поконкретнее...
Столь же целесообразно, сколь целесообразно использовать UDP - быстро, но ненадежно.
Зато перебирать порты не придётся... Чем не преимущество перед UDP ?
И вообще, обычно реализуют поиск сервера через MailSlot'ы ?
Anatoly Podgoretsky (2006-10-24 13:18:00) [12]
> мне надо всё быстро и сразу...
Быстро только кошки родятся.
Сергей М. (2006-10-24 12:40:00) [13]
> мне надо всё быстро и сразу
Ишь ты, О.Бендер нашелся) ...
> В справке есть эти коды ?
В справке есть все.
> В общем-то да...
Что значит "в общем-то" ?
Это, извини уж, похоже на "чуть-чуть беременна")
Сдается мне при этом, что ТЗ как такового не существует ..
> а делиться опытом ?
Делюсь - UDP быстр, но ненадежен, TCP надежен, но не быстр.
> Какие именно настройки ?
Профессионалу-сисадмину они д.б. известны.
И это вообще не твое (как разработчика) дело.
Твое дело - описать то что ты реализовал в ТР и представить его заказчику для согласования со специалистами по сет.администрированию.
> целесообразно ли их использовать для поиска сервера ?
Столь же целесообразно, сколь целесообразно использовать UDP - быстро, но ненадежно.
Cyrax (2006-10-24 11:57:00) [14]Проанализируй код этой ошибки, прежде чем делать какие-то дальнейшие поспешные умозаключения.
Нет, мне надо всё быстро и сразу...
В справке есть эти коды ?
Это оговорено в ТЗ ?
В общем-то да...
Выбирать тот или иной протокол и принимать решение придется в любом случае тебе, если это не оговорено в ТЗ.
... а делиться опытом ?
На то есть сетевой администратор - он обязан привести сет.настройки раб.станций в соответствие с особенностями и требованиями твоего софта.
Какие именно настройки ?
Отслеживание антивирусами сканирования портов блокировать нежелательно...
Одна из них - NamedPipes, в условиях ЛВС имеющая ряд ощутимых преимуществ перед технологиями/механизмами, ориентированными на Internet.
Насчёт NamedPipes гляну...
А вот по поводу MailSlot'ов: целесообразно ли их использовать для поиска сервера ?
Сергей М. (2006-10-24 11:09:00) [15]
> выбрасывается исключение Socket error
Проанализируй кодэтой ошибки, прежде чем делать какие-то дальнейшие поспешные умозаключения.
> 1. UDP-сервер никак нельзя сажать на заранее определённый
> порт - он может быть занят. Даже небольшой диапазон портов
> (10-20) в общем случае тоже может быть занят
Это оговорено в ТЗ ?
> Но если компов в локальной сети N немного, то поиск TCP-
> пакетами может оказаться ненамного дольше, чем поиск UDP-
> пакетами
Выбирать тот или иной протокол и принимать решение придется в любом случае тебе, если это не оговорено в ТЗ.
> нужно, чтобы такого "вирусного" эффекта не было, когда клиент
> будет искать сервер
На то есть сетевой администратор - он обязан привести сет.настройки раб.станций в соответствие с особенностями и требованиями твоего софта.
> Способов организации взаимодействия компов в сети, к счастью,
> не мало
Одна из них - NamedPipes, в условиях ЛВС имеющая ряд ощутимых преимуществ перед технологиями/механизмами, ориентированными на Internet.
Cyrax (2006-10-23 23:38:00) [16]У меня такая проблема.
Отсылаю широковещательный UDP-пакет серверу. Тот его принимает и отсылает клиенту ответ (TCP-порт). На клиенте я принимаю данные:
UDPBaseClient.RecieveData(buf,buflen). Но при выполнении этой команды выбрасывается исключение Socket error, не дожидаясь, пока пройдёт timeout мс, указанные в параметрах функции.
Пробовал принимать и через ReceiveString - то же самое...
Убрал отсылку ответа на сервере - то же самое...
Вообще убрал на клиенте отправку запроса серверу. Оставил только приём - всё нормально. Функция приёма ждёт timeout мс и успешно завершается безо всяких socket error...
Выходит, на клиенте при отправке запроса серверу (а эта операция происходит без ошибок) происходит что-то такое, что заставляет выбрасывать исключение на процедуре приёма данных на клиенте...
UDP-сервер у меня всегда активен при выполнении всех этих операций.
Теперь по поводу поиска сервера через UDP. 3 довода против такого подхода:
1. UDP-сервер никак нельзя сажать на заранее определённый порт - он может быть занят. Даже небольшой диапазон портов (10-20) в общем случае тоже может быть занят...
2. Если взять заранее определённый диапазон портов для UDP-сервера (скажем, 500 или 1000 номеров), то клиенту придётся их перебирать широковещательными UDP-пакетами. Здесь уже встаёт вопрос, стоит ли задействовать UDP, когда можно перебрать этот же диапазон портов (или чуть уже) TCP-пакетами, просто в N (число компов в локальной сети) раз дольше, чем в случае с UDP. Но если компов в локальной сети N немного, то поиск TCP-пакетами может оказаться ненамного дольше, чем поиск UDP-пакетами.
3. И вообще из этого может получиться следующее:
...покажу на примере живого анекдота про вирусную атаку:
Сижу на работе, отсылаю UDP-broadcast'ы по диапазону адресов. У одного начинает ругаться антивирус, потом у другого... Через некоторое время подходит начальство, говорит: "Ты Scada3 ?" - "Да". "От тебя вирусы лезут"...
Так вот, нужно, чтобы такого "вирусного" эффекта не было, когда клиент будет искать сервер...
Намекаю на другие способы организации поиска сервера. Способов организации взаимодействия компов в сети, к счастью, не мало. Например, mailslot'ы или другие технологии. К сожалению, опыта пока не достаточно, поэтому требуется совет компетентных в этой области...
Lamer@fools.ua (2006-10-20 08:56:00) [17]> 1. Как в винде посмотреть, какие порты в данный момент заняты и какими прогами (средствами винды, без программирования)
netstat — показывает активные соединения
Process Explorer (3rd party утилита) — показывает... много чего показывает :o)
Сергей М. (2006-10-20 08:36:00) [18]http://citforum.utmn.ru/programming/delphi/sockets-2/#08
Cyrax (2006-10-19 21:24:00) [19]Сергей М. © (18.10.06 12:52) [137]
реализуй в серверном приложении UDP-сервер на фикс.порту - он будет принимать UDP-бродкаст-запросы (простейшие в реализации !) клиентов и отвечать, на каком порту в дан.момент "слушает" соотв. TCP-сервер.
На фиксированном нельзя - может быть занят.
Если же брать диапазон - то придётся отправлять б-касты на все порты этого диапазона. Т.е., фактически клиент ищет UDP-сервер, отправляя б-касты на все порты диапазона, чтобы узнать IP-ник TCP-сервера...
Ну, и такой вопрос. Как можно поглядеть программно, какие порты заняты, чтобы вместо указания 0 в качестве порта программно найти свободный порт и туда посадить сервер ?
Это нужно, чтобы клиенту при поиске UDP-сервера пришлось шарить только этот диапазон...
А тебе посоветую не заниматься демагогией, а иззучить для начала хотя бы это
http://www.google.ru/search?q=Winsock+multicast&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:ru:official
Это всё, я так понимаю, для глубоких ламёров...
А что надо изучать ламёрам, пытающимся вырваться в юзёры ?.. :)
з.ы. Всё-таки TCP-мультикасту раскидать было бы проще...
Просто никто этого не хочет...
...или не может...
Сергей М. (2006-10-18 12:52:00) [20]
> предположим, так...
> И какой из всего этого можно сделать вывод ?
реализуй в серверном приложении UDP-сервер на фикс.порту - он будет принимать UDP-бродкаст-запросы (простейшие в реализации !) клиентов и отвечать, на каком порту в дан.момент "слушает" соотв. TCP-сервер.
> вы никогда не отправляли групповые TCP-пакеты
Я много чего еще не делал)
А тебе посоветую не заниматься демагогией, а иззучить для начала хотя бы это
http://www.google.ru/search?q=Winsock+multicast&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:ru:official