Connect to Internet-IP via a specific gateway

  • Thread starter Thread starter Matthias Springer
  • Start date Start date
M

Matthias Springer

Hi,

I'm planning to write a small .NET application which connects to a
server IP in the internet. As I have two internet connections there are
two possible ways to connect to the server - via IP1 and IP2.

Is there any possibility of choosing which gateway (router IP) to use
when connecting to the internet IP?

I'm running a Windows XP system and my program always chooses the
internet connection which is defined as the standard gateway.

Thanks.
 
In Matthias Springer
Is there any possibility of choosing which gateway (router IP) to use
when connecting to the internet IP?

In C, you'd use the "bind" function to attach your socket to a specific
local IP address (and port if you want or need to) before doing the
connect.

I'd hope that dotNet has a way to perform that operation.
 
In Matthias Springer


In C, you'd use the "bind" function to attach your socket to a specific
local IP address (and port if you want or need to) before doing the
connect.

I'd hope that dotNet has a way to perform that operation.

The binding of a socket doesn't determine the route the data takes; the
network stack with its routing information does that. If you are
connecting to an Internet IP address, and you have more more than one
network adapter connected to more than one gateway that can reach that
Internet IP address, then barring some explicit routing configuration, the
network stack will pick the one it thinks is best at that moment.

..NET has a Socket class that very closely mirrors the BSD-style Winsock
API, including a Bind() method. But that's only going to affect the IP
address used by the remote endpoint to reply, just as it would in Winsock
or using sockets on a Unix/Linux system.

That said, the original post is not very clear about what goal it is the
person is actually trying to achieve. It's possible that binding to a
specific IP address rather than 0.0.0.0 (IPAddress.Any) would suit his
needs, in spite of what the post appears to say.

If not, then if I recall correctly, one can provide routing configuration
via WMI, which is accessible through .NET. I don't have any of the
specifics, but that would be the way to do it if he really does need to
force a specific routing for the traffic.

Pete
 
In "Peter Duniho"
The binding of a socket doesn't determine the route the data takes;

It doesn't affect the "route" once the packet leaves the PC, but allows you
to attach your socket to a specific interface, if your machine has more
than one.
 
In "Peter Duniho"


It doesn't affect the "route" once the packet leaves the PC, but allows
you
to attach your socket to a specific interface, if your machine has more
than one.

No, not really. The remote endpoint will be guaranteed to see your
endpoint as that IP address, but there's no guarantee about how data from
your endpoint will get to the remote endpoint, even when the socket is
bound to a specific IP address.

Here are a few topics found scattered around the Internet that discuss
this very issue (mostly in terms of people complaining that when they use
bind(), the network traffic is still routed over a different adapter than
then one they wanted):

http://social.msdn.microsoft.com/Fo...m/thread/16782544-49cd-402a-8a45-1e1bf810eff4
http://mail.python.org/pipermail/python-list/2008-March/653002.html
http://lists.apple.com/archives/darwin-dev/2005/May/msg00244.html
http://www.developerweb.net/forum/showthread.php?t=3357

You'll note that the issue is a fundamental network implementation issue,
not unique to .NET at all. It exists across different frameworks and even
OS platforms.

Pete
 
In "Peter Duniho"
No, not really. The remote endpoint will be guaranteed to see your
endpoint as that IP address, but there's no guarantee about how data
from your endpoint will get to the remote endpoint, even when the
socket is bound to a specific IP address.

Nowhere do I mention the remote endpoint or the route your packet will
take to a remote endpoint, and the bind function doesn't either.

If your machine has multiple interfaces, each with a different IP
address, the bind function allows you to attach your socket to a
specific interface before performing a listen or connect.
 
Thank you for your fast answers.
If your machine has multiple interfaces, each with a different IP
address, the bind function allows you to attach your socket to a
specific interface before performing a listen or connect.

My machine has only one network interface. The computer is connected to
a switch and two routers (one for each internet connection) are
connected to the switch.
By setting the standard gateway to one of the router's IP on my machine
I can force Windows to send my packages through a specific internet
connection.

My .NET program should be able to send packages through a specific
internet connection (router, standard gateway) without changing the
standard gateway of the network adapter.

Therefore I want to send packages to one single IP address through both
internet connections simultaneously. I'm not familiar with routing but
this could perhaps make things more difficult.

It might not be relevant, but my goal is to write an application which
can balance network load on multiple internet connections.

Thanks.
 
In "Peter Duniho"


Nowhere do I mention the remote endpoint or the route your packet will
take to a remote endpoint, and the bind function doesn't either.

Whatever. The remote endpoint is implied in _any_ discussion of
networking, and you even quoted your own post where you "mentioned" the
"route". See above. I don't see how you can say that you didn't mention
it, given that it's there in plain view in your own previous post.
If your machine has multiple interfaces, each with a different IP
address, the bind function allows you to attach your socket to a
specific interface before performing a listen or connect.

Unfortunately, the word "attach" is at best a synonym for "bind", and at
worst has no precise technical meaning. Either way, saying that the "bind
function allows you to attach your socket" is either meaningless,
irrelevant, or incorrect. Take your pick.

The OP asked for control over which adapter is _used_, not which IP
address to which the socket is bound, so it's reasonable to assume you
were trying to answer the former question, not the latter. But your
answer doesn't address the former question, thus my reply.

If you _aren't_ trying to answer the question about how to control which
adapter is actually _used_, then you aren't trying to answer the question
that was asked. And that seems a little pointless.

Pete
 
[...]
My .NET program should be able to send packages through a specific
internet connection (router, standard gateway) without changing the
standard gateway of the network adapter.

Therefore I want to send packages to one single IP address through both
internet connections simultaneously. I'm not familiar with routing but
this could perhaps make things more difficult.

It might not be relevant, but my goal is to write an application which
can balance network load on multiple internet connections.

One might expect the network stack to deal with that on its own, though I
admit that normal desktop OSs, including Windows, may well not have that
feature. In any case, I don't believe you can control this sort of thing
programmatically with a socket, and for sure the Socket.Bind() method
isn't going to be helpful at all.

If you have control over both endpoints, your best strategy is probably
simply to create multiple connections, multiplexing the data yourself, and
hoping that the underlying network structure will correctly use both
available network connections for routing. I don't know whether it would,
but it's worth a try. If you can't even get it to work with multiple
sockets (for a test, don't even bother trying to keep the data streams
coherent...just send random data simultaneously over two connections and
see what kind of throughput you get), then I see very little hope in
convincing the network stack to multiplex a single socket connection on
your behalf.

And of course, if you don't have control over the remote endpoint, then
you're going to be entirely dependent on whatever features your platform
provides, such as that may be. There's not a configuration thing you can
adjust in the Socket class that would affect that, nor do I think you want
to be messing around with the routing on a real-time basis.

Pete
 
In "Peter Duniho"
Whatever.
Indeed.

The remote endpoint is implied in _any_ discussion of
networking,

No, it's not.
and you even quoted your own post where you "mentioned"
the "route". See above. I don't see how you can say that you didn't
mention it, given that it's there in plain view in your own previous
post.

The only mention of it was to exclude it from the discussion.

You're quite a piece of work.

Good luck in your future endeavors.
 
In "Peter Duniho"


No, it's not.

Interesting. You write network code that only ever uses one endpoint?
Amazing.
The only mention of it was to exclude it from the discussion.

Not that your "exclusion" was even accurate, inasmuch as it implied that
the binding affects the routing of data packets as they "leave the PC",
but you can't legitimately exclude it from the discussion anyway. The
discussion is entirely about the route the data takes. If you exclude
routing, you are talking about something entirely different from what the
OP is asking about.
You're quite a piece of work.

Good luck in your future endeavors.

Thank you for the compliment and positive thoughts.

Pete
 
I am going to answer this off the top of my head and risk someone saying
"you dumbass". LOL

From my understanding of networking, the issue is here is the IP routing
table and not directly a binding issue, as suggested by Bert. The question I
have, however, (not being a networking guy, although I have slept in a
Holiday Inn Express once) is whether or not the IP routing table in windows
is a firm ruleset, like in Cisco, or simply a strong suggestion.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

********************************************************
| Think outside the box! |
********************************************************
 
Back
Top