Проблемы при работе с Indy

← →
Ketmar © (2006-10-15 21:26) [120]

>[119] Cyrax(c) 15-Oct-2006, 20:09
>Если не поможет, буду отслеживать движение IP-пакетов и
>проводить всякие извращенские опыты...
ага. вместо чтобы написать простейший автомат... или по ходу обсуждения задача уже поменялась? лень перечитывать.

← →
Cyrax © (2006-10-15 23:10) [121]

Задача никак не менялась.
Могу написать простейший автомат и реализовать его в своём модуле. Будет некоторая надстройка (реализованная только в моём модуле и не выходящая за его пределы) над прикладным протоколом (неизвестным в общем случае). Ещё подумаю...
Но это всё будет после того, как разберусь с текущим глюком с отключением буферизации... - это садомазо такое (похоже на ситуацию с языковой панелью, которую я всё-таки вытащил наружу)...

← →
Ketmar © (2006-10-15 23:19) [122]

жениться бы вам, барин... (ц)

← →
Сергей М. © (2006-10-16 08:33) [123]

> Cyrax © (15.10.06 19:15) [117]

> Self.Socket.Binding.SetSockOpt(Id_SOL_SOCKET, Id_TCP_NODELAY,
> Char(@Id_SO_False), SizeOf(Id_SO_False));

Кто такой Self в данном контексте ?

Нагель отключается на уровне Id_IPPROTO_TCP.
Справку-то когда читать наконец научимся ?

← →
Cyrax © (2006-10-16 22:07) [124]

Ketmar © (15.10.06 23:19) [122]
жениться бы вам, барин... (ц)

Тогда останется один путь - повеситься...
Сейчас есть приоритеты и поважнее...

Сергей М. © (16.10.06 08:33) [123]
Кто такой Self в данном контексте ?

Ето наследник TIdTCPClient. Self я уже давно убрал. Он мне нужен был только чтоб добраться до SetSockOpt...

Нагель отключается на уровне Id_IPPROTO_TCP.

И на уровне Id_IPPROTO_TCP отключал, и на уровне... в общем, все уровни перепробовал... Везде одна и та же ошибка...

Справку-то когда читать наконец научимся ?

Где в справке указано, что... Вообще, где в справке хоть что-то описано об этих уровнях. Например, всё, что написано про Id_IPPROTO_TCP:
Id_IPPROTO_TCP = IPPROTO_TCP;

Unit
IdStackConsts
Description
Id_IPPROTO_TCP

И так про все константы, используемые в SetSockOpt...

_________________________________________________________________
Кто-нибудь отключал буферизацию TCP-пакетов с помощью SetSockOpt ?

← →
Ketmar © (2006-10-16 22:14) [125]

>[124] Cyrax(c) 16-Oct-2006, 22:07
>Кто-нибудь отключал буферизацию TCP-пакетов с помощью
>SetSockOpt ?
ну, я отключал. только как -- убей, не помню. и вспоминать лениво. давно было. где-то на "королевстве" была статья по работе с сокетами, там в том числе и об этом сказано.

← →
Cyrax © (2006-10-16 23:15) [126]

Ketmar © (16.10.06 22:14) [125]
ну, я отключал.

Ну вот, самому ведь приходилось, а говоришь код пиши правильно, буфера не трогай... $\g

где-то на "королевстве" была статья...

паоищу.. Глядел какой-то форум по этой функции, но на C++ - на паскале не прокатывает...

← →
Ketmar © (2006-10-16 23:35) [127]

>[126] Cyrax(c) 16-Oct-2006, 23:15
>Ну вот, самому ведь приходилось, а говоришь код пиши
>правильно, буфера не трогай...
я это делал "из спортивного интереса". в реальных задачах не приходилось ни разу.

← →
Сергей М. © (2006-10-17 08:33) [128]

> Где в справке указано, что... Вообще, где в справке хоть
> что-то описано об этих уровнях

Не ту справку ты куришь.

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

Следует курить как минимум справку MS Windows Sockets 2 Reference (поставляется штатно), где сказано:

level = IPPROTO_TCP*

TCP_NODELAY BOOL Disables the Nagle algorithm for send coalescing.
* - included for backward compatibility with Windows Sockets 1.1

BSD options not supported for setsockopt are:

...
TCP_NODELAY

The TCP_NODELAY option is specific to TCP/IP service providers. Enabling the TCP_NODELAY option disables the TCP Nagle Algorithm (and vice versa). The Nagle algorithm (described in RFC 896) is very effective in reducing the number of small packets sent by a host by essentially buffering send data if there is unacknowledged data already "in flight" or until a full-size packet can be sent ....

А еще лучше искать инф-цию в первоисточнике - MSDN.

> Везде одна и та же ошибка

В смысле "Access violation at address XXXXXXXX ...." ?

И чему равен XXXXXXXX ? Входит ли XXXXXXXX в диапазон адресов, распределенных под образ твоего модуля в ВАП процесса ?
Если входит, то в [117] - вранье, либо ты не умеешь пользоваться встроенным отладчиком.
Если не входит, то обязательно входит в диапазон адресов для образа какого-либо иного модуля, и эта инф-ция (т.е. какого конкретно модуля) не менее важна при поиске причин отказа.

← →
Verg © (2006-10-17 09:49) [129]

> Отсоединяюсь я методом Disconnect (пробовал и DisconnectSocket).
> При каждом очередном соединении клиента ОС выделяет ему
> новый порт. Если же задать порт клиента самому, то при повторном
> соединении возникает ошибка - порт то остался занятым...
>
> С TIdTCPServer такой проблемы не возникает.
>
> Что самое интересное, пример работы с TIdTCPServer и TIdTCPClient
> (IdTCPDemo), скачанный с инета, показывает те же результаты.
>
> На форумах читал, как обсуждали глюки некоторых компонентов
> Indy.
> Так вот, может это очередной глюк? Или отсоединяться (клиенту)
> нужно как то по-другому?

Это не от Indy.
см. http://book.itep.ru/4/44/tcp_443.htm
Состояние соединения TIME_WAIT.

← →
Cyrax © (2006-10-18 11:20) [130]

Тут такая задача подвернулась. Надо извратиться и отправить широковещательный TCP-пакет для поиска сервера...
А вообще, нужно максимально быстро найти сервер (с неизвестным IP-адресом и неизвестным портом из известных диапазонов), пользуясь только протоколом TCP/IP...

← →
Сергей М. © (2006-10-18 11:25) [131]

> нужно максимально быстро найти сервер

> пользуясь только протоколом TCP/IP...

Это что, блажь ? Чем это обосновано ? Чем UDP помешал ?

← →
Cyrax © (2006-10-18 11:31) [132]

Так извращеннее всего...
Ну, модуль у меня TCP-шный, кроме того, сервер может не поддерживать UDP...

← →
Сергей М. © (2006-10-18 11:52) [133]

> сервер может не поддерживать UDP

Что мешает реализовать в нем такую поддержку ?

← →
Cyrax © (2006-10-18 12:11) [134]

Допустим, сервер работает на основе сторонних модулей (а не моего), не реализующих поддержку UDP...

← →
Сергей М. © (2006-10-18 12:33) [135]

Да по барабану, на основе чего он там сейчас работает)
Если ты причастен к его разработке, то ты всегда волен реализовать сервер так как тебе нужно.

← →
Cyrax © (2006-10-18 12:45) [136]

Если ты причастен к его разработке, то ты всегда волен реализовать сервер так как тебе нужно.

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

з.ы. Видно, вы никогда не отправляли групповые TCP-пакеты...

← →
Сергей М. © (2006-10-18 12:52) [137]

> предположим, так...
> И какой из всего этого можно сделать вывод ?

реализуй в серверном приложении 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

← →
Cyrax © (2006-10-19 21:24) [138]

Сергей М. © (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-20 08:36) [139]

http://citforum.utmn.ru/programming/delphi/sockets-2/#08

← →
Lamer@fools.ua © (2006-10-20 08:56) [140]

>1. Как в винде посмотреть, какие порты в данный момент заняты и какими прогами (средствами винды, без программирования)

netstat — показывает активные соединения
Process Explorer (3rd party утилита) — показывает... много чего показывает :o)

← →
Cyrax © (2006-10-23 23:38) [141]

У меня такая проблема.
Отсылаю широковещательный 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"ы или другие технологии. К сожалению, опыта пока не достаточно, поэтому требуется совет компетентных в этой области...

← →
Сергей М. © (2006-10-24 11:09) [142]

> выбрасывается исключение Socket error

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

> 1. UDP-сервер никак нельзя сажать на заранее определённый
> порт - он может быть занят. Даже небольшой диапазон портов
> (10-20) в общем случае тоже может быть занят

Это оговорено в ТЗ ?

> Но если компов в локальной сети N немного, то поиск TCP-
> пакетами может оказаться ненамного дольше, чем поиск UDP-
> пакетами

Выбирать тот или иной протокол и принимать решение придется в любом случае тебе, если это не оговорено в ТЗ.

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

На то есть сетевой администратор - он обязан привести сет.настройки раб.станций в соответствие с особенностями и требованиями твоего софта.

> Способов организации взаимодействия компов в сети, к счастью,
> не мало

Одна из них - NamedPipes, в условиях ЛВС имеющая ряд ощутимых преимуществ перед технологиями/механизмами, ориентированными на Internet.

← →
Cyrax © (2006-10-24 11:57) [143]

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

Нет, мне надо всё быстро и сразу...
В справке есть эти коды ?

Это оговорено в ТЗ ?

В общем-то да...

Выбирать тот или иной протокол и принимать решение придется в любом случае тебе, если это не оговорено в ТЗ.

... а делиться опытом ?

На то есть сетевой администратор - он обязан привести сет.настройки раб.станций в соответствие с особенностями и требованиями твоего софта.

Какие именно настройки ?
Отслеживание антивирусами сканирования портов блокировать нежелательно...

Одна из них - NamedPipes, в условиях ЛВС имеющая ряд ощутимых преимуществ перед технологиями/механизмами, ориентированными на Internet.

Насчёт NamedPipes гляну...
А вот по поводу MailSlot"ов: целесообразно ли их использовать для поиска сервера ?

← →
Сергей М. © (2006-10-24 12:40) [144]

> мне надо всё быстро и сразу

Ишь ты, О.Бендер нашелся) ...

> В справке есть эти коды ?

В справке есть все.

> В общем-то да...

Что значит "в общем-то" ?
Это, извини уж, похоже на "чуть-чуть беременна")
Сдается мне при этом, что ТЗ как такового не существует ..

> а делиться опытом ?

Делюсь - UDP быстр, но ненадежен, TCP надежен, но не быстр.

> Какие именно настройки ?

Профессионалу-сисадмину они д.б. известны.
И это вообще не твое (как разработчика) дело.
Твое дело - описать то что ты реализовал в ТР и представить его заказчику для согласования со специалистами по сет.администрированию.

> целесообразно ли их использовать для поиска сервера ?

Столь же целесообразно, сколь целесообразно использовать UDP - быстро, но ненадежно.

← →
Anatoly Podgoretsky © (2006-10-24 13:18) [145]

> мне надо всё быстро и сразу...

Быстро только кошки родятся.

В справке есть все.

Гляну. Если что - буду ругаться...

Что значит "в общем-то" ?
Это, извини уж, похоже на "чуть-чуть беременна")
Сдается мне при этом, что ТЗ как такового не существует ..

Блин, ушли хрен знает куда... рожать...
Речь идёт о диапазоне адресов, с чего вопрос-то и начался. Ну так как быть с диапазоном портов для UDP-сервера...
Как вообще люди нормальный поиск сервера реализуют (самый распространённый вариант и чуть менее распространённые) ?

Делюсь - UDP быстр, но ненадежен, TCP надежен, но не быстр.

И это весь опыт-то ?

Профессионалу-сисадмину они д.б. известны.
И это вообще не твое (как разработчика) дело.
Твое дело - описать то что ты реализовал в ТР и представить его заказчику для согласования со специалистами по сет.администрированию.

Ну, допустим. С каким вопросом я должен обращаться к "специалистам по системному администрированию" - что-то вроде "Нужно как-то сделать что-то, чтобы антивирусники не ругались..." ?
Ну уж нет. Предпочитаю что-то поконкретнее...

Столь же целесообразно, сколь целесообразно использовать UDP - быстро, но ненадежно.

Зато перебирать порты не придётся... Чем не преимущество перед UDP ?
И вообще, обычно реализуют поиск сервера через MailSlot"ы ?

Они тебе ответят, прекрати скан атаку, администрация тебя уже предупредила и это первый звонок. В локальной сети подобные штуки делать, это ужас, вместо использования не вирус подобных методов.

> Гляну. Если что - буду ругаться...
>

Только не говори потом, мол, искал и не нашел, потому что не туда, мол, смотрел)

Ты инженер или где ?)

> Блин, ушли хрен знает куда... рожать...

Эт точно)... Но я тебя, заметь, за язык не тянул - ты сам начал за здравие и ты сам же продолжил за упокой)

> как быть с диапазоном портов для UDP-сервера...
> Как вообще люди нормальный поиск сервера реализуют

Они его никак не реализуют.
Они , эти самые люди, говорят так: вот вам, к примеру, очередной шедевр в виде такого-то POP3-сервера, оной по таким-то известным соглашениям "сидит" на 110-м порту, а ежели у вас 110-й порт занят, то сервер можно посадить и на любой иной порт, но это уже ваши проблемы.

> С каким вопросом я должен обращаться к "специалистам по
> системному администрированию" - что-то вроде "Нужно как-
> то сделать что-то, чтобы антивирусники не ругались..." ?
>

Да какое тебе нафих дело до антивирусников и прочей не относящиейся к твоей компетенции софтовой тряхомудии ?)

Ты - разработчик, а не кто-то иной !
Да мало ли какая гадость на компе заказчика может мешать работе твоего софта ! В известный момент времени это его, заказчика, проблемы)

В ответ на ТЗ ты сотворил свое подробное ТР и отправил его на согласование представителю Заказчика. Заказчик же тебе, к примеру, вернул отлуп, мол, ТР не годится потому-то и потому-то. Далее ты волен отказаться от реализации проекта, потому как не знаешь иного решения, либо предложить это иное решение.

> Зато перебирать порты не придётся

Что тебя на портах заклинило ?)

Ты софт свой для ЛВС разрабатываешь или для глоб.сети ?
В ТЗ оговорена обязательная реализация трансп.подсистемы на базе IP или это твоя отсебячина ?

С чего ты взял, что в случае mailslots никаких "переборов" нет и в помине ?
"Ты суслика видишь ? И я не вижу. А он есть !" (С)

> Да мало ли какая гадость на компе заказчика может мешать
> работе твоего софта

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

> Предлагаешь убить?

Я предлагаю автору представить заказчику подробное ТР, чтобы специалисты заказчика сами могли сделать заключение, годится им это решение или не годится.

> Я предлагаю автору представить заказчику подробное ТР

Это обязательно и если заказчик подпишет, то посылать лесом со всеми претензиями по безопасности, можно будет и отменить, но работу все равно оплатить и отдельно оплатить переделку, но я бы на месте заказчика серьезно задумался бы над подобным и послал бы автора по дальше и далее в соотвествии с договорами.
А если эта штука делается не по заказу, то сам понимаешь куда надо автора посылать?

Пока я не вижу ни одного разумного довода для подобной реализации.

> если эта штука делается не по заказу, то сам понимаешь куда
> надо автора посылать?

Конечно понимаю)

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

> в "начинающие" - в самый раз

Моя ошибка, исправлю

Удалено модератором
Примечание: Обсуждение модерирования, а насчет угроз пока будут считать, что шутишь, но забанить всегда успеем

> Cyrax © (24.10.06 19:03) [154]

> Желательно перекинуть эту ветку назад, либо меня забаннить
> (только 2 варианта)...

В качестве третьего предлагаю и то и другое.

--
Regards, LVT.

Удалено модератором
Примечание: Повесит здесь, но закрытая и не вздумай восстанавливать, смотри правила.

Проблемы при работе с Indy Найти похожие ветки