Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2009

Tip: Looking for answers? Try searching our database.

Detecting server on lan

Thread view: 
Ken T. - 02 Jul 2009 04:30 GMT
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?

Thanks.

Signature

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

 As we enjoy great advantages from the inventions of others, we should
 be glad of an opportunity to serve others by any invention of ours.
       -- Benjamin Franklin

Knute Johnson - 02 Jul 2009 05:28 GMT
> 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
[quoted text clipped - 11 lines]
>
> Thanks.

You can't just try to connect to the server?

Signature

Knute Johnson
email s/nospam/knute2009/

Ken T. - 02 Jul 2009 08:01 GMT
>> 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
[quoted text clipped - 13 lines]
>
> You can't just try to connect to the server?

That's the thing.. I don't know its IP address.  I want to detect it.

Signature

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

 The only two things that are infinite in size are the universe and
 human stupidity. And I'm not completely sure about the universe.  
       -- Albert Einstein

John B. Matthews - 02 Jul 2009 12:08 GMT
> >> 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
[quoted text clipped - 13 lines]
>
> That's the thing.. I don't know its IP address.  I want to detect it.

You might look into zeroconf/bonjour:

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

Signature

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

Tom Anderson - 03 Jul 2009 11:21 GMT
>>>> 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
[quoted text clipped - 4 lines]
>
> <http://en.wikipedia.org/wiki/Multicast_DNS>

This is exactly what i was going to suggest.

A java implementation:

http://jmdns.sourceforge.net/

tom

Signature

If this is your first night, you have to fight.

John B. Matthews - 04 Jul 2009 19:55 GMT
> >>>> 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
[quoted text clipped - 10 lines]
>
> 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>

Signature

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

Knute Johnson - 02 Jul 2009 17:09 GMT
>>> 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
[quoted text clipped - 14 lines]
>
> That's the thing.. I don't know its IP address.  I want to detect it.

OK, I understand what you are asking now.  The UDP packet idea sounds
pretty simple.  Just have the server broadcast to a specific address and
port with its IP address.  The clients can read the UDP packets and
connect to the sent address.  There is a range for multicast addresses,
take a look at the class MulticastSocket.  It has all the details and if
you know how to do UDP datagrams in Java you should be good to go.

Signature

Knute Johnson
email s/nospam/knute2009/

Roedy Green - 02 Jul 2009 07:29 GMT
>  Is there a simpler way to do what I'm trying to do?

I would implement some trivial transaction on the server, e.g.
what version are you? are you alive?

Then just send that as a GET HTTP packet.
Signature

Roedy Green Canadian Mind Products
http://mindprod.com

"Deer hunting would be fine sport, if only the deer had guns."
~ William S. Gilbert of Gilbert and Sullivan

Ken T. - 02 Jul 2009 08:04 GMT
>>  Is there a simpler way to do what I'm trying to do?
>
> I would implement some trivial transaction on the server, e.g. what
> version are you? are you alive?
>
> Then just send that as a GET HTTP packet.

OK, this isn't a web server.  This is a server I'm writing for part of
the program.  I won't know what machine it is running on.  So what I'm
trying to do is to detect what the ip address of the server is.  

The idea was that a client would scream out

"Marco"

on a broadcast address, and the server would answer,

"Polo"

by sending a UDP packet back to the client, thereby giving the client its
IP address.

If there is a better way to do this, please let me know.

Thanks.

Signature

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

 The optimist thinks this is the best of all possible worlds. The
 pessimist fears it is true.  
       -- Robert Oppenheimer

Steven Simpson - 02 Jul 2009 08:59 GMT
> I would like to have the client detect a server on a lan. [...]
>
> 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've not tried this, but I'd look at:

<http://java.sun.com/javase/6/docs/api/java/net/InterfaceAddress.html#getBroadcas
t%28%29
>

Get the InterfaceAddress for the NetworkInterface connected to the LAN
to want to broadcast on.  If you have no criteria for choosing one, you
could try them all.

Signature

ss at comp dot lancs dot ac dot uk

Nigel Wade - 02 Jul 2009 11:59 GMT
> 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
[quoted text clipped - 9 lines]
> 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?

Use the rmiregistry. That's what it's for.

Signature

Nigel Wade

Ken T. - 02 Jul 2009 22:32 GMT
>> 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
[quoted text clipped - 11 lines]
>
> Use the rmiregistry. That's what it's for.

That just pushes the problem one more step away...

How do I find the rmiregistry?  

Signature

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

 There are 10 types of people in this world:  those who understand
 binary and those who don't.

Lew - 02 Jul 2009 22:41 GMT
Nigel Wade wrote:
>> Use the rmiregistry. That's what it's for.

> That just pushes the problem one more step away...
>
> How do I find the rmiregistry?  

The RMI registry resides at a standard (a.k.a., "well-known") location as
documented in the RMI documentation.  Strengthen your Google-fu.

<http://search.sun.com/main/index.jsp?col=main-developer-all&qt=RMI+registry>
<http://java.sun.com/javase/6/docs/api/java/rmi/registry/Registry.html>
<http://www.javacoffeebreak.com/articles/javarmi/javarmi.html>
<http://java.sun.com/javase/6/docs/technotes/tools/index.html#rmi>

Signature

Lew

Ken T. - 03 Jul 2009 02:57 GMT
> Nigel Wade wrote:
>>> Use the rmiregistry. That's what it's for.
[quoted text clipped - 5 lines]
> The RMI registry resides at a standard (a.k.a., "well-known") location
> as documented in the RMI documentation.  Strengthen your Google-fu.

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?

Signature

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

 For every complex problem, there is a solution that is simple, neat,
 and wrong.
     -- H. L. Mencken

Lew - 03 Jul 2009 03:25 GMT
> 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.

Signature

Lew

Tom Anderson - 03 Jul 2009 11:17 GMT
>> 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
[quoted text clipped - 3 lines]
>
> 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!

tom

Signature

If this is your first night, you have to fight.

Nigel Wade - 03 Jul 2009 12:06 GMT
>>> 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
[quoted text clipped - 6 lines]
> 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.
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.

If you do anything else you are just inventing problems which don't need to
exist.

Signature

Nigel Wade

Michal Kleczek - 03 Jul 2009 12:15 GMT
>>>> You still have to have its IP address and my clients aren't running an
>>>> RMI
[quoted text clipped - 10 lines]
> But the WHOLE POINT rmiregistry, and network and server administration in
> general, is that the clients SHOULD KNOW.

Why?

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

Signature

Michal

Nigel Wade - 03 Jul 2009 17:46 GMT
>>>>> You still have to have its IP address and my clients aren't running an
>>>>> RMI
[quoted text clipped - 12 lines]
>
> 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.

Signature

Nigel Wade

Lew - 03 Jul 2009 18:56 GMT
>>>>>> You still have to have its IP address and my clients aren't running an
>>>>>> RMI
[quoted text clipped - 26 lines]
> 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.

Signature

Lew

Tom Anderson - 03 Jul 2009 13:31 GMT
>>>> 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
[quoted text clipped - 12 lines]
> 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. 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. 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.

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.

> 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. Remind me not to hire you to do
network architecture.

tom

Signature

A military-industrial illusion of democracy

Michal Kleczek - 03 Jul 2009 14:13 GMT
[snip]
> zeroconf *is* a better way. AppleTalk did something almost identical
> twenty years ago, which made it far and away the easiest networking system
[quoted text clipped - 3 lines]
> 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 :)

Signature

Michal

Ken T. - 03 Jul 2009 15:26 GMT
> [snip]
>> zeroconf *is* a better way. AppleTalk did something almost identical
[quoted text clipped - 13 lines]
> 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.

Thank you all for your assistance though.

Signature

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

 A distributed system is one in which the failure of a computer you
 didn't even know existed can render your own computer unusable.
    -- Les Lamport

Michal Kleczek - 03 Jul 2009 16:17 GMT
>> [snip]
>>> zeroconf *is* a better way. AppleTalk did something almost identical
[quoted text clipped - 16 lines]
> 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>

Signature

Michal

Nigel Wade - 03 Jul 2009 16:26 GMT
>>>>> 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
[quoted text clipped - 14 lines]
>
> 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
[quoted text clipped - 3 lines]
> 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.

Signature

Nigel Wade

Ken T. - 03 Jul 2009 17:14 GMT
> 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.  

Signature

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

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

Nigel Wade - 06 Jul 2009 16:10 GMT
>> 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
[quoted text clipped - 19 lines]
> 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.

Signature

Nigel Wade

Patrick May - 04 Jul 2009 23:22 GMT
> 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
[quoted text clipped - 10 lines]
> 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_Discovery_Service_Specification

Regards,

Patrick

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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.