Ken T. wrote:

> On Fri, 03 Jul 2009 15:13:42 +0200, Michal Kleczek wrote:
>
>> Tom Anderson wrote:
>>
>> [snip]
>>> 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 Sun did invent something better as well - technology called Jini.
>> For some reason it is not as widely used as it deserves.
>>
>> To answer OP's question:
>> 0. Read
>> http://jan.newmarch.name/java/jini/tutorial/Jini.html 1. Implement you
>> server as a Jini service 2. Implement your client as a Jini client 3.
>> Run a lookup service on your network 4. You're done
>
> This is all getting far too complex for the problem I'm trying to solve.
> I'll look into multi-cast udp and see if that solves the problem.

It may look like it's complex but look at the code below. It achieves
everything you need without doing any low level network programming (and it
is not an easy thing to do actually).
The only thing needed is a lookup service running somewhere on the network.
Implementation of a lookup service is part of Jini Starter Kit (it's called
Reggie). The simplest thing to do is to run it on the same machine as your
server.

<code>
public interface MyServiceInterface extends Remote {
public void myMethod() throws RemoteException;
}

public class TestServer implements MyServiceInterface {

private final MyServiceInterface myProxy;
private final JoinManager joinManager;

public TestServer() throws ExportException, IOException {
final Exporter exporter = new BasicJeriExporter(
TcpServerEndpoint.getInstance(0), new BasicILFactory());
myProxy = (MyServiceInterface) exporter.export(this);
joinManager =
new JoinManager(myProxy, null, (ServiceID)null,
new LookupDiscovery(LookupDiscovery.ALL_GROUPS),
new LeaseRenewalManager());
}

@Override
public void myMethod() {
}

private synchronized void justStayAlive() throws InterruptedException {
wait();
}

public static void main(String[] args) throws Exception {
new TestServer().justStayAlive();
}

}

public class TestClient {

public static void main(String args[]) throws Exception {

final ServiceDiscoveryManager sdm =
new ServiceDiscoveryManager(
new LookupDiscovery(
LookupDiscovery.ALL_GROUPS), new LeaseRenewalManager());

//wait forever for a server
final ServiceItem item = sdm.lookup(
new ServiceTemplate(
null, new Class[] {MyServiceInterface.class}, null),
null, Long.MAX_VALUE);

if (item != null) {
MyServiceInterface myService = (MyServiceInterface) item.service;
myService.myMethod();
}

}

}
</code>

--
Michal

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

On Fri, 03 Jul 2009 16:26:41 +0100, Nigel Wade wrote:

> 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.

I think the point he's making is that the question itself was based on
not having this information.

> 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.

This is the real reason I'm following up. I don't have any problem with
getting broadcast to work except that the typical broadcast used in every
other language isn't supported by Java. That isn't a limitation of my
skill, but of the platform. Implementing this in C would have been quite
easy.

Also, your suggested solutions assume a level of sophistication on the
part of my client that I don't think is present. The reason I presented
the question the way I did was because that was the problem I was trying
to solve. Your stating that I really don't need the problem solved is
simply a misunderstanding of the environment in which I'm working.

That said, I do appreciate your input.

--
Ken T.
http://www.electricsenator.net

The natural progress of things is for liberty to yield and for
government to gain ground. -- Thomas Jefferson

Michal Kleczek wrote:

> 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.
>>
>
> Why?

Because you end up with a simple, working, solution in a matter of minutes. It's
easy to understand and easy to configure and maintain. If it's a small network
then a simple solution is probably going to be the best option. The main
question is does the OP need anything more complicated?

>
> Ever heard of ad-hoc networking, service discovery, randezvous, mdns, jini
> etc. etc.?

If the OP has the programming/technical resources necessary to implement one of
the above approaches then fine, let them go ahead and do so. All you need to do
is tell them how.

The problem the OP has could be solved by using rmiregistry on a known server.
It's only one solution, it may not be acceptable to the OP (I don't know that),
but it *is* a solution, and a very simple one.

--
Nigel Wade

Nigel Wade wrote:
> Michal Kleczek wrote:
>
>> 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.
>>>
>> Why?
>
> Because you end up with a simple, working, solution in a matter of minutes. It's
> easy to understand and easy to configure and maintain. If it's a small network
> then a simple solution is probably going to be the best option. The main
> question is does the OP need anything more complicated?
>
>> Ever heard of ad-hoc networking, service discovery, randezvous, mdns, jini
>> etc. etc.?
>
> If the OP has the programming/technical resources necessary to implement one of
> the above approaches then fine, let them go ahead and do so. All you need to do
> is tell them how.
>
> The problem the OP has could be solved by using rmiregistry on a known server.
> It's only one solution, it may not be acceptable to the OP (I don't know that),
> but it *is* a solution, and a very simple one.

Nigel, I would hire you to maintain a network in a New York minute, were that
my job responsibility. By inference, ditto for hiring you as a software
developer.

--
Lew

In article <alpine.DEB.1.10.0907031117410.8525@urchin.earth.l i>,
Tom Anderson <twic@urchin.earth.li> wrote:

> On Thu, 2 Jul 2009, John B. Matthews wrote:
>
> >>> Ken T. wrote:
> >>>> I would like to have the client detect a server on a lan. So
> >>>> there will be some 30 clients on the same lan as a single server
> >>>> and when they start I want them to be able to find the server
> >>>> and automatically connect to it for using RMI.
> >
> > You might look into zeroconf/bonjour:
> >
> > <http://en.wikipedia.org/wiki/Multicast_DNS>
>
> This is exactly what i was going to suggest.
>
> A java implementation:
>
> http://jmdns.sourceforge.net/

Thanks, Tom, I enjoyed looking at this project. I also found two other
browsers, described here:

<http://en.wikipedia.org/wiki/Bonjour_Browser>

The Java implementation was a student project, and it includes a nice
report on the effort:

<https://wiki.cs.columbia.edu:8443/display/res/JBonjourBrowser>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

"Ken T." <nowhere@home.com> writes:
> I would like to have the client detect a server on a lan. So there
> will be some 30 clients on the same lan as a single server and when
> they start I want them to be able to find the server and automatically
> connect to it for using RMI.
>
> My idea was to have them send out a UDP packet to the broadcast
> address and then have the server respond saying, "Here I am!", but I'm
> having difficulty figuring out how to send a UDP packet to the
> broadcast address of the lan.
>
> I tried just sending it to "255.255.255.255", but this didn't work.
> Is there a way to detect the broadcast address? Is there a way to
> send a packet to it? Is there a simpler way to do what I'm trying to
> do?

You can use the Jini (http://www.jini.org) discovery mechanism. A
good start is here:

http://www.jini.org/wiki/Jini_Lookup..._Specification

Regards,

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation. (C++, Java, Common Lisp, Jini, middleware, SOA)

Ken T. wrote:

> On Fri, 03 Jul 2009 16:26:41 +0100, Nigel Wade wrote:
>
>> 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.
>
> I think the point he's making is that the question itself was based on
> not having this information.
>
>> 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.
>
> This is the real reason I'm following up. I don't have any problem with
> getting broadcast to work except that the typical broadcast used in every
> other language isn't supported by Java. That isn't a limitation of my
> skill, but of the platform. Implementing this in C would have been quite
> easy.
>
> Also, your suggested solutions assume a level of sophistication on the
> part of my client that I don't think is present. The reason I presented
> the question the way I did was because that was the problem I was trying
> to solve. Your stating that I really don't need the problem solved is
> simply a misunderstanding of the environment in which I'm working.

I had misunderstood your problem domain.

I didn't intend to mean that your problem didn't need solving. Rather that one
solution to the problem would be to shift the problem domain i.e. move it from
the domain of broadcast service location to that of a simple static network.

My assumption was that the information necessary to do this would be available,
just that you didn't happen to have it. The simple solution does require you to
be in full control of the network and for the network to be suitably configured
already. I now understand that that is not the case, so it won't work.

I hope you find a suitable method, Michal Kleczek's does look worth
investigation. I tried to follow the link he posted but the server was not
responding when I requested it.

--
Nigel Wade