Two ethernet cards/networks (still)

B

Bob Greschke

There is a lot to stuff that seems to skirt around this issue (most of which
has to do with finding your IP address), but I can't find anything that
explains how to write a client that (in my case) needs to collect some
information from some equipment on a private network/Ethernet card, then
transmit that info on the other Ethernet card/"outside" network to another
program (which will put it into a db).

"binding to a specific address is almost never used for a client", sez
Foundations of Python Network Programming, but is that how it's done?? Each
card has a fixed IP address. It's on Windows at this time if that makes any
difference.

Thanks!

Bob
 
S

Steve Holden

Bob said:
There is a lot to stuff that seems to skirt around this issue (most of which
has to do with finding your IP address), but I can't find anything that
explains how to write a client that (in my case) needs to collect some
information from some equipment on a private network/Ethernet card, then
transmit that info on the other Ethernet card/"outside" network to another
program (which will put it into a db).

"binding to a specific address is almost never used for a client", sez
Foundations of Python Network Programming, but is that how it's done?? Each
card has a fixed IP address. It's on Windows at this time if that makes any
difference.
The reason that "binding to a specific address is almost never used for
a client" is because it's the server destination address that the
network layer will use to determine which interface is used to
communicate with a specific server host.

Suppose your network setup looks like this:


+-------------------+------------------------+ Network A
|
|
|
| 192.168.12.34/24
|
+--------+--------+
| |
| |
| YOUR HOST |
| |
| |
+--------+--------+
|
| 201.46.34.22/24
|
|
|
+-------------------+----------+-------------+ Network B
|
+
+--------+--------+
| router |
| to internet |
+-----------------+

If your client program tries to communicate with, say, 192.168.12.18
then by the IP network layer will automatically select network A as the
medium, since the destination is local to that network. If you then want
to communicate the results to 201.46.34.118 then network B will be used,
again because the destination is local to that network (its first 24
bits are the same as the first 24 bits of the destination).

In this case the router on network B will almost certainly be the
default route for the host, as it's the way to everywhere else.

This isn't really Python-related, so I hope it answers your question!

regards
Steve
 
B

Bob Greschke

Steve Holden said:
Bob Greschke wrote:
The reason that "binding to a specific address is almost never used for a
client" is because it's the server destination address that the network
layer will use to determine which interface is used to communicate with a
specific server host.

Suppose your network setup looks like this:


+-------------------+------------------------+ Network A
|
|
|
| 192.168.12.34/24
|
+--------+--------+
| |
| |
| YOUR HOST |
| |
| |
+--------+--------+
|
| 201.46.34.22/24
|
|
|
+-------------------+----------+-------------+ Network B
|
+
+--------+--------+
| router |
| to internet |
+-----------------+

If your client program tries to communicate with, say, 192.168.12.18 then
by the IP network layer will automatically select network A as the medium,
since the destination is local to that network. If you then want to
communicate the results to 201.46.34.118 then network B will be used,
again because the destination is local to that network (its first 24 bits
are the same as the first 24 bits of the destination).

In this case the router on network B will almost certainly be the default
route for the host, as it's the way to everywhere else.

This isn't really Python-related, so I hope it answers your question!

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Nice explanation! Thanks! You mean I don't have to do anything special??
That sounds suspiciously easy. :)

To muddy the water a little the equipment I want to get info from (some
seismic digitizing/recording equipment) comes back to us from the field with
the IP addresses set to whatever that last user needed. What we do now is
put the unit(s) on the bench, connect them to the private network and use a
broadcast address (like 255.255.255.255) and a specific port number to query
and see who is connected. Then we (a program) can get in (login, basically)
and reset the all of the IPs to the same subnet to proceed with checkout,
calibration, etc. We have to disconnect from (or disable the card for) the
outside network when we do this discovery or else the program discovers all
of these instruments that we have running in the building (monitoring a
seismic pier, in people's offices, etc.). I'm guessing here we will still
need to do this? It's not a biggie, but finding a way to not have to do
this was what started this whole thing. Once the program knows which
instruments it found on the private network it doesn't matter. It will only
work on those ones.

Thanks!

Bob
 
S

Steve Holden

Bob said:
Nice explanation! Thanks! You mean I don't have to do anything special??
That sounds suspiciously easy. :)

To muddy the water a little the equipment I want to get info from (some
seismic digitizing/recording equipment) comes back to us from the field with
the IP addresses set to whatever that last user needed. What we do now is
put the unit(s) on the bench, connect them to the private network and use a
broadcast address (like 255.255.255.255) and a specific port number to query
and see who is connected. Then we (a program) can get in (login, basically)
and reset the all of the IPs to the same subnet to proceed with checkout,
calibration, etc. We have to disconnect from (or disable the card for) the
outside network when we do this discovery or else the program discovers all
of these instruments that we have running in the building (monitoring a
seismic pier, in people's offices, etc.). I'm guessing here we will still
need to do this? It's not a biggie, but finding a way to not have to do
this was what started this whole thing. Once the program knows which
instruments it found on the private network it doesn't matter. It will only
work on those ones.

Ah, so you want to do a limited broadcast over a single interface (the
one for the private network) to avoid having to disable the other
interface? That's a different kettle of fish.

I suspect you could do it by binding the local socket to a single
address, but I'd need to play around to get it right. Maybe someone else
has already done this?

regards
Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top