Доброго времени всем! Появилась задачка, которую уже долгое время не могу решить - потому прошу помочь...

Имеется: два сетевых интерфейса с разными IP, масками, шлюзами и т.д. По обоим "приходит интернет" :)

Задача: программно "переключать" интерфейсы и через каждый из них послать GET-запрос (http) на внешний сервер.

с HTTP работаю, использую компонент idHTTP - с этим проблем нет. Запросы посылаются, ответы приходят, все ОК. Но все это дело проходит только по тому сетевому интерфейсу, который назначен в системе основным (метрика наименьшая). Менять метрику для всей системы не очень приятно.
Думаю, можно решить это дело локально, в контексте только моего приложения?

> По обоим "приходит интернет"


> Но все это дело проходит только по тому сетевому интерфейсу,
> который назначен в системе основным (метрика наименьшая)
> .

значит другой простаивает...

> значит другой простаивает...

Кэп, как мне Вас не хватало... =D

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


У IdHTTP для этого есть св-во BoundIP

[2] я намекал на то, что если у тебя используется фактически только один интерфейс, зачем дергать за другой? или у Вас нагрузка распределяется по обоим?

> или у Вас нагрузка распределяется по обоим?

во время простоя одного из интерфейсов приложение должно проверять состояние его IP...

> Задача: программно "переключать" интерфейсы и через каждый
> из них послать GET-запрос (http) на внешний сервер.

точнее, через каждый интерфейс посылать запрос на внешку для определения IP, затем, если IP для одного из интерфейсов изменился - нужно переключить всю систему на этот интерфейс (например, с помощью вызова команды "route ..."). Определять приходится через внешку потому, что машина находится за роутерами.


> У IdHTTP для этого есть св-во BoundIP

Да, я это свойство опробовал. Обнаружил такую проблему:
Если в системе оба интерфейса с одинаковой метрикой, то использование BoundIP дает желаемый результат. Если же метрика одно из них ниже (т.е. приоритет выше), то использование свойства BoundIP не дает желаемого результата: запрос передается через интерфейс с более высоким приоритетом, но с адресом (в BoundIP) другого интерфейса, что приводит к невозможности подключения к внешнему хосту =(

> если IP для одного из интерфейсов изменился

так это может быть только в одном случае и имхо маршрут просле реконнекта меняется сам...

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

Описываю:

Первый интерфейс - сетевая карта. Машина за роутером, имеет свой статический локальный IP. На другой стороне роутера "приходит интернет" ))

Второй интерфейс - ADSL-модем (usb).

В итоге имеем два внешних IP (динамические) и один локальный (статический)

Смену IP на модеме я могу отследить простым вызовом некоторых функций (локально, без танцев с бубном), а вот узнать о смене внешнего IP за пределами роутера - это возможно только с помощью внешнего хоста, который "увидит" мой IP "оттуда" и сообщит мне его в http-ответе. А для этого нужно указать маршрут именно через роутер (через сетевую карту). Вот такие пироги...

у Вас каша в голове... советую ознакомиться с основами tcp/ip сетей, многие вопросы отпадут...
зы. ip просто так не меняеются "находу"

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

с основами ip-сетей прекрасно знаком, так что вопрос остается открытым...

p.s. Внешние IP присваиваются провайдером, меняются динамически примерно раз в сутки (иногда чаще)

удачи!

> удачи!

спасибо, именно это мне сейчас и необходимо...

> интерфейса с одинаковой метрикой


Метрика она вообще-то не у интерфейса, а у маршрута.

Если два маршрута к одной и той же целевой подсети/хосту проходят через два разных шлюза в одной и той же подсети источника, то иначе как расстановкой нужных приоритетов маршрутов (метрик) задача на прикладном уровне не решается.

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

И судя по

> два сетевых интерфейса с разными IP, масками, шлюзами и  т.д


биндинг к нужному "разному IP" обязан решить задачу.

При условии что интерфейсы по чьей-то неразумности или прихоти не сконфигурированы так что подсети пересекаются, например, так:

if1: 192.168.0.3/24 gw 192.168.0.1
if2: 192.168.0.4/16 gw 192.168.0.2

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

> Метрика она вообще-то не у интерфейса, а у маршрута.

да, эт я просто уже "задрыгался" с ручной настройкой маршрутов из командной строки - "интерфейсы", "метрика"...

1 канал: локалка, настроена банально: ip=192.168.1.10, шлюз=192.168.1.1, маска=255.255.255.0
за "локалкой" стоит роутер с выходом во внешку (пример автоматически получаемых настроек: ip=37.99.11.50, шлюз=37.99.11.50, маска=255.255.255.255)

2 канал: ADSL, получает настройки от DHCP автоматом (например, такие: ip=95.57.77.131, шлюз=95.57.77.131, маска=255.255.255.255)

Ну и ?
Биндишься к 192.168.1.10 - ходишь в Тырнет через 192.168.1.1 (а он, в свою очередь, через 37.99.11.50, если у него там на борту с маршрутами не понахреноверчено)

Биндишься к 95.57.77.131 - ходишь туда же, но уже через 95.57.77.131

ага, вот тут-то и начинается "магия"...

192.168.1.10 метрика=1, 95.57.77.131 метрика=10, idHTTP1.BoundIP:='95.57.77.131'
подключение неудачно

95.57.77.131 метрика=1, 192.168.1.10 метрика=10, idHTTP1.BoundIP:='192.168.1.10'
подключение неудачно

единственный случай, когда это "прокатывает" - если метрика выставлена одинаковая (например равная единице)

что может быть не так (с системой / с руками / с мозгом)?

> подключение неудачно

подключение происходит удачно, но через тот интерфейс, через который в системе прописан приоритетный маршрут (метрика=1)