Предположим что udp (indi или другой без разницы) клиент посылает пакет на удаленный хост на закрытый udp порт.
Смотрим в фаервол и видим что пришел icmp result либо с самого хоста либо с маршрутизатора "получатель не доступен".
Процесс system.exe вроде.
1) А как я могу получить чтобы потом обработать данный пакет в Дельфи?

2) И правильно ли я полагаю что одним из способов провереять наличие хостов в сети можно посылая пакет на udp и в случае если ответил хост то он жив а в случае если маршрутизатор то хост мертв?

Ты хочешь PING сделать что ли?

> 2)


Неправильно.

> guard_gg  (19.01.2008 18:01:00)  [0]

А если не пришел, то бросаем монетку?

Пинг делать не хочу, он и так есть =)

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

Если не пришел то значит или киска его сьела или порт открыт
так что шутка не удалась, теорию udp я немного знаю

///////////////////////////////////////////////////////////////////////////
Если конкретно то нужно мне научиться работать на нижних уровнях программирования сокетов. Чтобы просто при отсылании пакета на удаленный udp порт уметь получать результат и както обрабатывать програмно
Пока что приходиться тестировать проект за счет фаервола и самому ему результат подсказывать =D

>[4] guard_gg (22.01.08 02:09)
>нужно мне научиться работать на нижних уровнях программирования сокетов
udp не является «нижним уровнем».

> Чтобы просто при отсылании пакета на удаленный udp порт
> уметь получать результат и както обрабатывать програмно

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

На нижнем уровне ПРОГРАММИРОВАНИЕ СОКЕТОВ а НЕ OSI!!!
то есть НЕ способом "кинул компоненту на форму а та и заработала"

---------------
Логика такая:
-- Если результат не прийдет - то OPEN / FILTERED
{тоесть либо открыт и можно продолжать передачу данных, либо его отфильтровал маршрутизатор выясниться уже при попытке заговорить с конкретном сервисом}

-- Если прийдет от маршрутизатора или хоста ICMP "получатель не доступен" то проинформировать об этом пользователя в виде ошибки соединения

Ну я же не прошу Вас выкладывать выкладывать военные тайны в повышенном обьеме. просто прошу в двух предложениях сказать где копать и как =)

Если кто сможет скинуть examle на любом из языков программирования кроме ассемблера =) то буду весьма благодарен

Великий гугл про сокеты детскую инфу предлогает.

Я бы сам смог разобраться да вот тока в модулях INDI .pas файлов нету, тока компилированные .dcu. прочие компоненты с сокетами такие же. копирайт всетаки =(

А под WinSock даже как я понял из WinSDKHelp даже сокета навороченного не создашь. нужен winsock2 модуль

> На нижнем уровне ПРОГРАММИРОВАНИЕ СОКЕТОВ а НЕ OSI!!!

Ты бред то не неси откровенный. Нижний уровень модели OSI ты хоть знаешь как называется и к чему относится? Нижний уровень - физический.

Тебе же доступен максимум 3 уровень - сетевой, на котором функционирует протокол IP в частности. И все уровни выше.


> Я бы сам смог разобраться да вот тока в модулях INDI .pas
> файлов нету, тока компилированные .dcu. прочие компоненты
> с сокетами такие же. копирайт всетаки =(

Исходники есть в интернет на сайте инди.


> А под WinSock даже как я понял из WinSDKHelp даже сокета
> навороченного не создашь. нужен winsock2 модуль

Ну и используй WinSock2. Заголовочный файл WinSock2.pas везде валяется.


> Ну я же не прошу Вас выкладывать выкладывать военные тайны
> в повышенном обьеме. просто прошу в двух предложениях сказать
> где копать и как =)

Ты по человечески объясни по шагам, что ты хочешь сделать. Ибо из написанного выше мало понятно.

По человечески:
Как перед отправкой сообщения на UDP порт узнать открыт он или нет?
(кратко как только смог)

Если порт никто не слушает, то следующий send вернет ошибку, а WSAGetLastError вернет WSAECONNRESET.

2 guard_gg

Чтобы получить результат, сокет должен быть "соединенным". Вывод - нужно подключить сокет, т.е. Connect(...)

PS На всякий случай - я видел, что UDP.

Да, после этого разумеется придется использовать Send вместо SendTo etc.

> Andru ©   (06.02.08 09:44) [10]
> Если порт никто не слушает, то следующий send вернет ошибку,
>  а WSAGetLastError вернет WSAECONNRESET

А не recv / recvfrom??
Все равно полной гарантии нет в получении такого сообщения...


> ага   (06.02.08 12:17) [11]

В UDP Connect - это скорее для упрощения работы... имхо.

2 Evgeny V

> В UDP Connect - это скорее для упрощения работы... имхо.

Одно другому не мешает. По сути SendTo/RecvFrom внутри делают тот-же Connect, потом отправку, потом отключение. При каждом вызове. Вот и получается, что ты отправил SendTo, пакет ушел в сеть, на него пришел ответ "нетути такого", а система не знает, кому его отдать. Ну и выбрасывает, ясен пень. А если сокет подключенный, то система видит - "вот он, отправитель. Шлет, понимашь, куды ни попадя, пусть сам с ошибками и разбирается."

> Одно другому не мешает. По сути SendTo/RecvFrom внутри делают
> тот-же Connect, потом отправку, потом отключение. При каждом
> вызове. Вот и получается, что ты отправил SendTo, пакет
> ушел в сеть, на него пришел ответ "нетути такого", а система
> не знает, кому его отдать. Ну и выбрасывает, ясен пень.
> А если сокет подключенный, то система видит - "вот он, отправитель.
>  Шлет, понимашь, куды ни попадя, пусть сам с ошибками и
> разбирается."
>


(пробовал но не уверен)
Ну даж не знаю, обычно все пакеты result svchost.exe кушает и не с кем не хочет делиться даж если сокет пытается recv делать
На счет Send/To не уверен так как сообщение error не узнавал че возращает.
А вот Recv как раз таки на закрытый порт заставляет Application окно с ошибкой выдавать. Естественно предполагал что можно по OnException обрабатывать да только мне показалось что слишком криво это все получаться бут. Я же всетаки надеялся что можно результат будет получать нормальным путем и обрабатывать основываясь на содержимом пакета а не ошибке приложения

> А вот Recv как раз таки на закрытый порт заставляет Application
> окно с ошибкой выдавать. Естественно предполагал что можно
> по OnException обрабатывать да только мне показалось что
> слишком криво это все получаться бут.

Чево? В сад.

> Чево? В сад.

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

ага   (06.02.08 12:17) [11]
Connect
какой конект? UDP - мессаже ориентированный протокол... т.е. "соединение" состоит из 1 единственной, никчему не обязывающей датаграмы... а полноценное соединение как минимум подрузумевает handshake хотябы примитивный, а это минимум 2 пакета: туда и обратно

> ага   (06.02.08 18:09) [14]


> Вот и получается, что ты отправил SendTo, пакет ушел в сеть,
>  на него пришел ответ "нетути такого", а система не знает,
>  кому его отдать. Ну и выбрасывает, ясен пень. А если сокет
> подключенный, то система видит - "вот он, отправитель.

это интуитивно?:-)
Нет.
И в том и в другом случае получаем один результат, по recv/recvfrom получаю ошибку 10054. Могу дать код на С#, если есть желание проверить в отладчике два варианта, с Connect и без него, когда и как выскакивает ошибка. А можешь и сам написать на winsock.


> guard_gg   (06.02.08 18:32) [15]

Насчет кривости - не знаю Indy, не работаю давно в дельфи,но в .Net например все ошибки сокетов передаются через SocketException, так что try / catch (try/ except  в дельфи) вполне помогают. Но повторюсь, в любом случае нет 100%-ой гарантии, что что ты получишь что-то обратно в качестве ответа.

> Slym ©   (07.02.08 06:14) [18]

Тем не менее вызов Connect для UDP сокета осуществить можно:-) Он просто устанавливает адрес удаленного хоста по умолчанию, что бы можно было пользоваться функцией send, без явного указания адреса получателя. Соединения как в TCP конечно нет.

2 Evgeny V ©

> это интуитивно?:-)
> Нет.

Что "нет"? Что не интуитивно? Да, не интуитивно. Откуда? Из самых разных источников. Например, сейчас под рукой Йон Снейдер, "Эффективное программирование TCP/IP", стр.234 - 238. Глава так и называется "Совет 30. Разберитесь, что такое подсоединенный UDP-сокет". Типа намек, ага?

> И в том и в другом случае получаем один результат, по recv/recvfrom
> получаю ошибку 10054

Какой нафиг Recv? Вопрос читал?

> Могу дать код на С#, если есть желание проверить в отладчике
> два варианта, с Connect и без него, когда и как выскакивает
> ошибка.

Не, не надо. Тем паче на обшарпанном. У меня того кода - завались.

> ага   (07.02.08 13:25) [21]

Нет -это значит под Windows это не так. Про книгу
У меня есть эта книга, там он пишет о ВCD и  unix, под Windows не все так реализовано. Кроме того я читал о connect, sendTo и много очем  в MSDN - и там надо сказать написанное мягко говоря противоречит кое-чему написанному у Снайдера (хотя бы тому же sendTo и присоединнму UDP сокету). А так как лучше проверить, чем просто верить, попробуйте протестировать. Напишите код и посмотрите. Или опять я вам предлагаю по шагам пройтись в коде, который я вам пришлю, только написан он на C#
И вот выдержка из MSDN
"The sendto function is normally used on a connectionless socket to send a datagram to a specific peer socket identified by the to parameter. Even if the connectionless socket has been previously connected to a specific address, the to parameter overrides the destination address for that particular datagram only. On a connection-oriented socket, the to and tolen parameters are ignored, making sendto equivalent to send.", а вот что пишет Снайдер -
"updconnl: ошибка вызова sendto: Socket is already connected (56)

bsd: $

Ошибка произошла из-за того, что вы вызвали sendto для подсоединенного сокета. При этом sendto потребовал от UDP временно подсоединить сокет. Но UDP определил, что сокет уже подсоединен и вернул код ошибки EISCONN."
Разница очевидна. Просто пишет он для юникс сокетов и книга надо сказать хорошая, но MSDN пишет для реализации Windows. Так что одних книг маловато будет... Надо бы и код иногда писать и проверять или просматривать MSDN.

"Представим, что надо послать UDP-датаграмму, но никакой процесс на другой стороне не прослушивает порт назначения. Протокол UDP на другом конце вернет ICMP-сообщение о недоступности порта, информируя тем самым ваш стек TCP/IP, но если сокет не подсоединен, то приложение не получит уведомления. Когда вы вызываете sendto, в начало сообщения добавляется заголовок, после чего оно передается уровню IP, где инкапсулируется в IP-датаграмму и помещается в выходную очередь интерфейса. Как только датаграмма внесена в очередь ( или отослана, если очередь пуста ), sendto возвращает управление приложению с кодом нормального завершения. Иногда через некоторое время ( отсюда и термин асинхронный ) приходит ICMP-сообщение от хоста на другом конце. Хотя в нем есть копия UDP-заголовка, у вашего стека нет информации о том, какое приложение посылало датаграмму (...). Если же сокет подсоединен, то этот факт отмечается в управляющем блоке протокола, связанном с сокетом, и стек TCP/IP может сопоставить полученную копию UDP-заголовка с тем, что хранится в PCB, чтобы определить, в какой сокет направить ICMP-сообщение."
Йон Снейдер (c).

Имеющий глаза - да прочитает, имеющий мозги - да поймет.
Я все сказал. Хау. Что в переводе на русский означает "ага".

ага   (07.02.08 13:25) [21]
что такое подсоединенный UDP-сокет
Скорее всего имеется ввиду заBindеный сокет Bind(Socket,...)

>[23] Evgeny V © (2008-02-07 13:51:00)
дык давно не секрет, что bsd-sockets и winsock — звери, похожие только внешне. и макияж криво на winsock нанесен.

---
Understanding is not required. Only obedience.

> ага   (07.02.08 13:34) [22]

вызов recv возвращает ошибку о недоступности хоста, если была отправлена датаграмма на закрытый порт - это было комментарием к
> Andru ©   (06.02.08 09:44) [10]

, это работает суди по всему работает и у автора вопроса , что подтвердил и автор в
> guard_gg   (06.02.08 18:32) [15]

Если это не относится к теме вопроса, то ваш
> ага   (06.02.08 12:17) [11]
относится еще меньше, впрочем как и последующие посты.

И че, что на винде она перекрывает адрес, если вызвать sendto на подключенный сокет? Че это меняет по сути? В общем, не работает - значит не работает. А мне это все приснилось.

> ketmar ©   (07.02.08 13:58) [26]

Знаю, вопрос вроде идет в дельфи и по виндам:-)


> Slym ©   (07.02.08 13:57) [25]

Нет о подсединенном, к которому была вызвана функция connect, в MSDN есть о connect и UDP

> ага   (07.02.08 14:01) [28]

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

> У ваша манера мне напоминает другой ник или даже пару ников,

Ну, у нашу манеру обсудить - святое дело, спору нет как раз в тему:)

Ну ладно, MSDN так MSDN. Не будет ли любезен многоуважаемый Evgeny V разъяснить мне, неразумному, смысл данной цитаты из MSDN:

send Function
...
WSAECONNRESET

The virtual circuit was reset by the remote side executing a hard or abortive close. For UDP sockets, the remote host was unable to deliver a previously sent UDP datagram and responded with a "Port Unreachable" ICMP packet. The application should close the socket as it is no longer usable.

Дабы не возникло подозрений в фальсификации, укажу адрес, откуда была взята вышеприведенная цитата:
http://msdn2.microsoft.com/en-us/library/ms740149.aspx

> ага   (07.02.08 17:00) [31]

А что вам не понятно в этой цитате? Вам нужен перевод или вы хотите спросить что-то или обратить на что-то мое внимание?
На то, что ошибку вернет send? Я вам уже предлагал код, которым можно проверить цитаты. Я вам предлагал написать самому код, если вам не хочется воспользоваться своим и кодом показать, что и как работает. Вы склонны цитировать "библии". Я верю и MSDN и Снайдеру, но каждому в  своем случае(юниксу юниксово, а виндовсу видовсово), а еще больше я верю опыту, кода пишешь код и получаешь результат... Так вот по вами данной цитате -не возвращает у меня send на законекченном сокете udp ошибку, даже два и три раза и более раз подряд вызываю send вызов проходит успешно, а вот первый же после  send вызов recv вернул 10054.
Операционная система у меня стоит лицензионная Widows XP SP2. Аналогичное происходит и на соседнем компьютере у коллеги -тот же XP SP2
Сокет в блокирующем режиме если вам интересны подробности.

> guard_gg   (06.02.08 18:32) [15]

Судя по всему у автора вопроса присходит то же самое
Вывод MSDN тоже не панацея, читать надо, только обращать внимание на то что читаете и проверять в случае сомнений...  Попробуйте написать свой код и проверить у себя. Будут другие результаты с интересом ознакомлюсь.
Я не противник того, что могу да и на самом деле часто ошибаюсь. Но, не посылаю всех в сад
> ага   (06.02.08 19:17) [16],

на том основании, что у кого-то результаты опыта не такие, как я прочитал в какой-то из книг. Если ошибаюсь, то признаю это. Так что присылайте свой исходный код, проверим посмотрим, сравним... Есть дельфи - правда дома, на работе есть студия - можете выбрать дельфи или c# - я
PS: Проверил у коллеги на дельфи с WinSock, результат тот же,  send -нет ошибки, повторysq send - нет ошибки, recv ошибка 10054 Сокет UDP блокирующий и законнекченный....

> Evgeny V ©   (08.02.08 06:32) [32]

Извиняюсь за ошибки в посте, писал не за один раз... работа..

Соотвественно фраза была не закончена в

> Есть дельфи - правда дома, на работе есть студия - можете
> выбрать дельфи или c# - я


читать как
 Есть дельфи - правда дома, на работе есть студия - можете
выбрать дельфи или c# - я посмотрю  код на любом из этих языков...


> повторysq send - нет ошибки

читать как повторный send

>Но, не посылаю всех в сад > ага   (06.02.08 19:17) [16],

Блин:(
И че? Какое мне дело, кого куда вы там посылаете/не посылаете? Вы меня собираетесь учить морали? А с каких интересно пирогов? Вы собсна, кто таки а? У вас что, патент на самую моральную мораль среди мировых моралей? От кого? От ООН? От ЮНЕСКО? От лиги сексуальных меньшинств?
Да что ты будешь делать - куда ни ткни пальцем, везде носитель высшей морали под руку подвернется:( И обязательно тя учить норовит.


>Так что присылайте свой исходный код, проверим посмотрим, сравним

Ага. Щас. Тока тапочки почищу, а то че-то не блестят.
Блин:(

> ага   (08.02.08 12:12) [34]


> Ага. Щас

Я вам предлагал проверить на моем коде C#, а  сейчас есть и на дельфи, но я так понимаю отладчиком по десятку строчек пройтись трудно или не умеем? На нет и суда нет. Учить вас - упаси боже...