|
Boots111 has asked for the wisdom of the Perl Monks concerning the following question:
Hey all, I am new to Perl and PerlMonks (I started teaching myself this spring). anyway I have an internship at a company that produces software for the PalmOS.
In the debug phase of everything we run Gremlins on POSE (Palm OS Emulator). The only problem is that gremlins take forever to run and each computer that does this produces its own result file. Thus what my task for this summer is to create a distributed client-server system for these gremlins.
I have the very basics of this system running right now; however, it is not pretty.
The whole system is currently on Win 2000; however, I would like to make the client software flexible enough to work on Macs also.
Right now, the server has two subdirectories (requests and results). The client drops a "request file" into the requests directory. The server sees the request and drops a command file into the client's directory. The client then processes the command file and sends places a report in the results box. All of the network communication is done using network paths and letting Windows handle the actual network communication...
I would like to do many things with this and don't even know how to begin.
To do:
Have client connect to server directly rather than using files and drop boxes.
Provide pretty GUI for set-up and running
If anyone has ideas about how I could improve this sort of system or has tried something like this before I would like any help that I could get. I would publish code but it is not incredibly pretty and I don't think it would help explain my goal, so I shall leave the system abstract for now.
Thanks
|
Re: Client-Server system
by tadman (Prior) on Jun 22, 2001 at 01:30 UTC
|
A true client-server system, where you have written both ends
of the application, is very powerful, but it is also quite
involved to write. The client itself is fairly simple in
principle. It is when you begin to write the server that
things start to get involved. Handling multiple incoming
sockets in one connection versus having many different
processes and trying to coördinate between them, and many
other things that you will discover. Maybe someone will be
kind enough to point out a module that does this for you,
or at the very least, makes it easier.
If you want a quick and dirty solution, which is where all
good things start anyway (Perl included), then you might
want to use a combination of CGI and LWP.
Apache is a great
"server", and is likely better than any one you could write
yourself in a few months, although IIS would also do the
job with a little configuration. Use LWP on the client
end to perform the data transfer. LWP::Simple is trivial
to use, and you can always "upgrade" to full LWP::UserAgent
later.
Here's the basics. Write some CGI programs that provide data
to the clients. These clients will check the server
on a regular basis for new data. They will read their
instructions, download any appropriate data via HTTP,
and then report their findings using POST to a form on
the server.
If you want to make a GUI, use TK. It's cross platform,
and is a little wacky, but works well once you get a handle
on it.
Now when I say "quick and dirty", what I mean is that you can
get going very quickly using standard CPAN modules. This
does not prevent you from improving the quality of your
application over time, of course. Try hacking out something
that works, and then if you want to write it again "properly",
you will already have a good understanding of the application
and can do a much better job than if you planned out the first
one extensively and then built something that wasn't quite what you
expected. | [reply] |
Re: Client-Server system
by andreychek (Parson) on Jun 22, 2001 at 05:02 UTC
|
That's a very interesting problem you are looking to solve. There is an open source instant messaging platform called Jabber. It works similar to AIM or ICQ, but is free, and you don't need to use any one company's server, you can set one up on your own.
What is intriguing about this is that the same way you and I can talk to each other via instant messages, so could any two given applications. A way some are looking to use Jabber is very similar to what you are looking for -- to allow multi-tier applications to talk to one another.
You would simply have your client and server log in to the Jabber server using a particular ID. Once they know each other's Jabber ID (JID), they can speak to one another.
There are several advantages to this approach. First, you don't have to worry about any of the message passing details. Client libraries have been developed already for many popular languages, including Perl, Python, PHP, C, etc (the Perl library is known as Net::Jabber). You simply make use of various API calls to send and receive messages. Also, since there are so many supported languages, it doesn't matter what language you write your programs in. Of course, we all prefer Perl here.. but in some cases, life isn't that easy, and for one reason or another we need to use another language. With Jabber, no problem. It also has an open API, uses XML for message passing, and has a company backing it, showing that it won't be going out of style any time soon.
For communicating between your applications, you could use SOAP::Lite or something similar, and embed those within the Jabber XML messages.
There are two versions of Jabber -- an open source an commercial version. The commercial version has a few extra features, and is more scalable. You could choose between the two, depending on your needs.
One big problem you may run into then, is that you said you are running on Windows 2000/Mac. Jabber only runs on UNIX/Linux. Now, with Jabber, you could set up a Linux box in the corner to run the Jabber server on, and keep everything else on your Windows and Mac boxen. But if you are unable to do that, you'd have to wait until the Windows port is finished, which is supposedly under way.
At one point in time, there had been a project under way known as JAM -- Jabber as Middleware. It was designed to take Jabber to the next level as far as Middleware goes. Unfortunatly, the people working on it just haven't had time to put into it, and it appears to be on hold at the moment. If you're interested in pushing, check out the Jam Dev Mailing List. Do be sure to look through the archives first to get a better idea what it is (and dizzyd is the ring leader), but you can also send a message to see if anyone is still alive :-)
Good luck!
-Eric | [reply] |
|
|
Actually the Jabber server is apparently only available in Linux version. Clients exist for all kinds of platforms (didn't see a Palm version yet tho).
Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur.
| [reply] |
|
|
> Actually the Jabber server is apparently only
> available in Linux version. Clients exist for
> all kinds of platforms(didn't see a Palm version yet
> tho).
Right, but I did mention that in my previous post ;-)
Again though, the ideal method of handling this case would be to toss a Linux box in the corner running the Jabber server -- perhaps on Gigabyte Ethernet -- and just let the Windows and Mac Boxen access the Jabber server via the network.
One thing I forgot to mention in my original post though is that both versions of Jabber were designed to be scalable, and if you find that running a Jabber server on one box isn't fast enough, you can do some form of load balancing to help offset some of the traffic.
We're actually beginning to tinker with using Jabber for this purpose here at my workplace, I'll be sure to post the results of how it all goes.
-Eric
| [reply] |
|
|
Re: Client-Server system
by particle (Vicar) on Jun 22, 2001 at 01:50 UTC
|
i'm pretty new to perl, too. but this site is a good place to look for info. in fact, just a day or two ago, jdgamache posted this nugget Client / Server app. in general, try a search on 'client server'. there's lots out there.in fact, if you find something cool, let me know. i've just started looking at client/server code. remote execution of some of my code would make life much easier.
~Particle | [reply] |
|
|
