Предположим что 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%-ой гарантии, что что ты получишь что-то обратно в качестве ответа.