Re: resolving ip address to a specific network
From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 03/10/04
- Next message: P Gentry: "Re: Strange network behavior"
- Previous message: Laconsults: "Next Generation TCP/IP Instant Guaranteed Service Technology : needs only add few lines in Linux stack source codes"
- In reply to: Alan Walkington: "Re: resolving ip address to a specific network"
- Next in thread: David Efflandt: "Re: resolving ip address to a specific network"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 9 Mar 2004 20:26:18 -0800
"Alan Walkington" <alan[REMOVE]@walkington.net> wrote in message news:<FFl3c.10254362$Of.1702321@news.easynews.com>...
> "David Efflandt" <efflandt@xnet.com> wrote in message
> news:slrnc4r94o.kva.efflandt@typhoon.xnet.com...
I have cross-posted this in an attempt to tie these threads together
so everyone can see what's up.
> <SNIP>
> >
> > > I have a 'master' system. There are a couple of computers networked on
> eth0,
> > > and a couple on eth1.
Again, is the "master" acting as a router or as a bridge? Does it
have a third interface connecting to the internet, eg.?
> > > I want to open a socket to an IP address on eth1.
Sockets are opened by a process (or more accurately, by code running
in a process) that will map to a port #. Eg., http servers will
"listen" on port 80 using a socket created/owned by the httpd process.
Clients "call" servers by requesting a connection on a particular IP
address and port # using the appropriate protocol. The server (or
more likely a daemon on behalf of the server) will be listening for
traffic on a particular IP address at a particular port #. What
process (server) are you trying to have open a socket? What client
will be sending it connection requests?
> > > I have no clue how to tell sockets which device the ip address is on.
Sockets are connected to processes running on a machine with one or
more IPs, not particular IP addresses per se.
> > > Any help would be appreciated.
> >
> > If you have proper interface netmasks and routing, anything should
> > automatically use the proper interface (first route in list that matches,
> > or default if no other). How do you think your web browser knows which
> > interface to use if you have both an internet connection and LAN
> > interface? So either avoid conflicting networks and routing, or see the
> > Adv-Routing HOWTO.
>
> Thanks for the response, David.
>
> There are two networks, one each on /dev/eth0 and /dev/eth1. A destination
> machine may be on either or both.
>
> Consider that the machine 'Mach1' is on both nets. ...
Remember, machines only "host" the interfaces that are actually bound
to an IP. Mach1 has one interface on one net and another interface on
the other net. It "hosts" both interfaces. It's usually a "big"
mistake to have one machine with two interfaces on the same network
segment!
> ... I want to make a socket
> connection to it on /dev/eth1. (Priority traffic is using /dev/eth0, and I
> want to avoid collisions). My DNS resolves Mach1 to an IP address. One IP
> address.
The client making the request has no authority to create or open
sockets on another machine. It makes requests to an IP:Port# pair
using a particular protocol. The server (the listening/answering
machine) creates the socket(s) needed to establish and maintain a
connction. Sockets are just locations in memory owned by a
particular process -- "foreign" machines have no knowledge of or
access to another machine's memory space. The client creates sockets
(mapped to port #s) on its machine to set up and maintain its end of
the connection. That's why IP uses inet addresses to route packets
and TCP/UDP uses port #s (mapped to process owned sockets) to stream
packets to a process (a.k.a. a network application).
> So I still am clueless as how to specify which device (/dev/eth0 or
> /dev/eth1) to use for this socket() call.
Applications, by the code they run, request sockets with system calls
to the machine they run on. They are _totally_ ignorant of the
network architecture at the physical level -- ie., ignorant of
ethernet, Token Ring, fddi, ppp or anything else. Likewise, the
physical data link layer is ignorant of port #s and sockets.
> Sorry I'm so thick-headed.
We are all born equally ignorant -- nothing to be sorry for. You
probably need to read up on the networking howtos available at:
http://www.tldp.org/docs.html
>
> Alan Walkington
> United Defense, Santa Clara
It would be best if you gave us detailed info about your network
layout and precisely what it is you're trying to do. From combining
what you've written in both NG postings, I suspect you're trying to
"shape" the IP traffic flow with policy routing. This is _very_
difficult stuff and is _always_ specific to a particular network setup
and goal. It's almost _never_ appropriate in a small network except
for testing/learning.
In fact, I'm not sure where you got the notion that there is a
"command" to open or create a socket. Sockets are created in
application (binary) _code_ by making a system call. Are you trying
to write a networking application? If so, using what language? For
what purpose? The end user should be and should remain ignorant of
"sockets" -- except the ones needed to plug-in their equipment.
I am clueless as to _what_ you are trying to accomplish, but I'm
certain "socket commands" are not the solution to anything.
For some background on sockets, type this at the command prompt:
[user@pbrain]$ man socket
hth,
prg
email above disabled
- Next message: P Gentry: "Re: Strange network behavior"
- Previous message: Laconsults: "Next Generation TCP/IP Instant Guaranteed Service Technology : needs only add few lines in Linux stack source codes"
- In reply to: Alan Walkington: "Re: resolving ip address to a specific network"
- Next in thread: David Efflandt: "Re: resolving ip address to a specific network"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
