> Sorry, but Java isn't my language, so I'm showing my ignorance.
>
[quoted text clipped - 4 lines]
> hour?, and replies can be an integer from 0 on up. The language in the
> spec is Java.
> In order to best tailor the answer for your situation, can you give
> some background information: This sounds like a fairly complicated
[quoted text clipped - 4 lines]
> application before? What programming languages are you familiar with? How
> familiar are you with the TCP/IP protocol? etc.
I work in an IT department of a large state university. I am a
database guy, and my strength is Perl. I write a lot of file
manipulation scripts, where I input one data file, process it, and
output it in another form. It's all data related, and over the years
we've amassed quite a bit of scripts, undocumented and frankly
unmaintainable. I've written one largish Java app, participated in
about six more, and am probably an advanced beginner/low intermediate
in Java. I don't do network programming, at least not until now.
The order of the day is, move to Java, stop using Perl, convert
everything over. Obviously, we'll continue to do the one-off things in
Perl, but we have several big apps that really do need to be in Java
simply for the sake of maintaining them.
> If you're familiar with the TCP/IP protocol, you would probably be
> aware that in order to connect to a specific computer and exchange data
> with it, that computer needs to be listening on some port, and your
> connecting computer would need to specify the port when connecting.
Yeah. My background is as a web developer and server administrator, so
I understand HTTP, TCP/IP, Apache, FTP, CGI, etc. This is where I
learned Perl.
> You would also probably be aware that there must be some software on
> these listening computers which will do something with the data they
> receive from listening to those ports.
>
> What that software is and what is does is critical to being able make
> any progress.
This may sound funny, but it's really a prototype to test the
feasibility of a proposed system. I might not be the guy who should be
doing this, but I'm the guy with the project, and I'm really 'the'
programmer in my department. I don't know the eventual use, but I've
got a real set of requirements -- build an application that will
deploy an (arbitrary) number of clients that will self execute,
listen, and reply to requests. Writing the server was easy, and using
the UDP socket interface wasn't difficult. I'm just stuck on getting
the clients going. I can install and start the client programs on
several machines manually, but that doesn't meet the requirements.
CC
RedGrittyBrick - 21 Mar 2007 23:05 GMT
>> In order to best tailor the answer for your situation, can you give
>> some background information: This sounds like a fairly complicated
[quoted text clipped - 45 lines]
> the clients going. I can install and start the client programs on
> several machines manually, but that doesn't meet the requirements.
What services are available on the client nodes? ftp? sftp? telnet? sshd?
Lew - 21 Mar 2007 23:42 GMT
Are you able to start apps on the client nodes via an administrative process
or shell script, that is, not using Java? That would simplify things.
Have all new client processes send to the central server and request
instructions, then block until the server replies. The server would maintain a
pool of clients who have "checked in", and send replies (only) to those to
whom it must issue instructions. Then it does nothing with that client until
it next sends its "I'm ready" message.
That way the server never needs to know how many clients are out there until
they are ready. It never needs to know where they are, or what ports are open.
There is one server host (or cluster) with a well-known single open port. This
is much simpler than managing a geometrically increasing web of clients.
Keep the server "always" running (as a server should be). The clients report
in whenever they are available. Multiple client instances can run on a single
machine, which helps in testing.
-- Lew