Re: Detecting server on lan
Tom Anderson wrote:
On Fri, 3 Jul 2009, Nigel Wade wrote:
Tom Anderson wrote:
On Thu, 2 Jul 2009, Lew wrote:
Ken T. wrote:
You still have to have its IP address and my clients aren't running an RMI
registry now on any machine. At their site there is no standard location
for the RMI registry.
Maybe I'm missing something. Is there a way to locate the RMI registry on
the local area network?
When you run the registry, you will know on which machine you ran it.
The WHOLE POINT of this thread is that the machines which need to find
the registry DO NOT know which machine it was run on!
But the WHOLE POINT rmiregistry, and network and server administration in
general, is that the clients SHOULD KNOW.
A server should ideally be at a fixed IP address. Alternatively it should
have a
fixed hostname, and dynamic DNS can be used to provide the dynamic IP
address.
This is both remarkably arrogant, and remarkably backward.
Arrogant? Where do you get that from? To suggest an approach which would work is
not arrogant. To dismiss such a suggestion out-of-hand surely is arrogant
Firstly, if the
OP tells you that he doesn't have a globally-known IP for the server, then
telling him to get one is not an answer.
Firstly, I didn't tell them to get one, so get off your arrogant horse. I
suggested that getting one would solve their problem. Getting one is most
certainly an answer to the OPs problem, but you seem to think that a simple,
workable solution is not a valid answer.
Secondly, using globally-know
fixed IP numbers, or hostnames, or port numebrs to identify a service is
not an intrinsically good idea, it's just the way we've had to do things
because we didn't have a better way of doing it.
It is a very good way of doing things. It's worked very well for around 30
years, and still works now. In fact, pretty much the entire Internet is
underpinned by network servers running with known hostnames and services
operating on well-know ports.
If there is a better way, why isn't it being used?
zeroconf *is* a better way. AppleTalk did something almost identical
twenty years ago, which made it far and away the easiest networking system
to use. When Sun invented RPC, they tried to at least get rid of fixed
ports by using a port mapper. SRV records and all the kinds of directory
service are also attempts to move away from the fixed-address concept.
There is a long, long history of serious efforts to do the exact opposite
of what you suggest.
And just how many of them actually work reliably? What chance do you think a
single programmer on their own has of achieving something similar when they are
struggling to even get broadcast to work.
If you follow this simple rule with your network administration the OPs
"problem" becomes a non-issue. It would take about 5 minutes to
implement the former of these options.
And when you later need to move the server? Or have two servers? Oh, you
have to go and reconfigure *every* client.
That's the only solution you can think of? Personally I'd use DNS, I'm surprised
that you've never heard of it.
Remind me not to hire you to do
network architecture.
Ditto.
I've offered a practical, workable, solution which can be configured in a matter
of minutes. You've offered concepts, with no workable solution for the OP.
Instead, why don't you supply real instructions to the OP to configure one of
your alternative concepts and get it working in a similar amount of time.
--
Nigel Wade