Should I use IPC? Perhaps something else...*shrug*

snafu has asked for the wisdom of the Perl Monks concerning the following question:

Hello fellow monks, I have been thinking about this one for sometime now and I just have not been able to come up with a sound solution.

I have a server that allows interactive use from the clients. The server talks to the clients using udp messages and logs everything that goes on. The clients that connect to the server have a unique ability to be able to send a single udp packet to each other or anything else listening on a port somewhere for a udp packet. The server can be remotely administered if sent the proper information.

So, to recap, I have a server that can be monitored two ways

Via logfile

Via remote commands (mostly...not fully)

and

The clients can send message requests somewhere via a udp message.

I want to be able to monitor the server for client requests and then react to those requests at the server level. The thing that makes this so difficult is:

In order to watch the logfile, I have successfully created a routine that can watch the logfile with a tail -f like ability. This code however, is a true loop in itself...

Now, the next thing I decided to do was set up the ability to create a UDP server in perl so that the client can talk to my server and send requests that way. The thing that makes this difficult is:

The UDP server listens via a true loop.

See my problem? I can't have two true loops running independently of each other simultaneoulsy can I?

Here is what I have thought of doing; modular construction of the script. Create a main script that handles the spawning of two children processes that talk to the main script. The two children processes will actually be the network piece and the logfile watching piece. They will tell the main piece what to do which has the networking code in place to talk to the server.

My question is this: Is this the best way to go? Is my idea capable of working or should I think of some other more foolproof way? I have never used IPC before, but perhaps this would be a decent time to learn? Should I use IPC?

TIA

----------
- Jim

Comment on Should I use IPC? Perhaps something else...shrug

Replies are listed 'Best First'.
Re: Should I use IPC? Perhaps something else...shrug by no_slogan (Deacon) on May 10, 2001 at 01:33 UTC
You can set up a select() loop that checks both the logfile and the socket for input. But those are a big pain in the neck to write and maintain. My advice is to look into using Poe, which takes care of the gory details for you. Then you can write your log-tailer and your udp-server as separate Poe processes.	[reply]
Re: Should I use IPC? Perhaps something else...shrug by repson (Chaplain) on May 10, 2001 at 09:45 UTC
I've got just one question on this program... Why do you need to keep on reading from the logfile when no clients are requesting updates? It would seem better/easier to simply keep the logfile filehandle open then check for new data on it when a client sends a request. This way the program only needs one loop, and you avoid any unnecessary IPC headaches.	[reply]
Re: Re: Should I use IPC? Perhaps something else...shrug by snafu (Chaplain) on May 11, 2001 at 03:12 UTC
Good question. The way the server works is that everything that goes on on the server gets logged. I not only want this script to interact with the client but I also want the script to help me "watch" the server which can only be done by watching the logfle. Interacting with the client is just part of the responsiblities of this script. Another reason is that the client won't be able to interact with the script via the network until he/she requests help from the script. This means that the client needs to type a request (which gets logged) first using a command (defined in the script...like "server_help" or something) and that the script watches for. The fact that the client program has the ability to send udp messages is usually not known by the client user. At least not until the client user makes that request that will then get logged on the server which will then be caught by the logwatcher and in turn react by telling the client user how to talk to the script via the network. Every subsequent request should be made via the clients' ability to send network messages but I could fall back on the log at any time. Redundant? Yes...necessary? I think so. I hope this all made sense. I started it before work and then finished afterward. ---------- - Jim	[reply]