A couple of points - you really want to have 'unconnected' network operations here. I.e. you open the link every time you need to do something.
And the you want to go have a look at SOAP::Lite. Quick and easy network messaging and RPC. ____________________
Jeremy
I didn't believe in evil until I dated it. | [reply] |
Thanks for the help. Yes the clarification is that the client and server have a established connection whatsoever happens. They are bound by sockets. I need to do a recursion like function which would notify me of the changes that took place in the database. Typically a messenger service.
The fact is that, threads are still experimental in perl and callbacks are difficult to implement. In these circumstances, recursion leads to stack getting dumped and the server getting too busy with the looping.
One more problem is how do I check whether the client is listening all the time, he might have long back exited the program, server keeps sending to pipe which doesn't exist, you can use ping style of loopback to check if the client is receiving or not, crude isn't it.
I thought of another method, like using two intermediate clients. Let me explain, I have a server with Unix socket connected to /tmp/data which does the database operation, a client(1) is connected thru Unix socket to the server. This client(1) will in turn act as server for TCP-IP based socket and a windows client(2) will get the notification.
Please give your valuable feedback for these methods.
Gurudutt
| [reply] |
Nup. My clarification is that you should drop the 'permanent connection' approach and go with a transaction approach.
You are taking the wrong approach in recursing through a database to find changes. Either the database or the program which inserts the changes has to be responsible for alerting other programs to the changes.
When your database grows large (if it grows large) you will be putting a heavy load on the database server.
Don't use threads, use forks in perl
'Ping' the client to see if it is still up. If the client quits while the pipe is open, the server will get a sigpipe when it tries to write to the socket.
By your slightly confused explanation I am guessing that you haven't firmly settled on what you want to do. I recommend do what is easiest, which may involve patching the original program.
____________________
Jeremy
I didn't believe in evil until I dated it.
| [reply] |
If you are maintaining the connection with the client and if you are using a Forking server or a pre-forking server (such as Net::Server::Fork or Net::Server::PreFork), you can work out a little bit of a multiplex solution.
In this scenario, the parent server process maintains the child server processes which in turn handle a connection to a client process. If they stay connected, the parent can occasionally timeout and start another process to get the new information (using the dequeue method of Net::Server) and then communicate the new information to the child server processes via a pipe.
The child server processes would need to select on the client socket and on the pipe from the parent (IO::Select makes this easy). This is the multiplex part. The child process can then get updates from the parent which it sends on down to the client process.
This is not necessarily a trivial task, but if you use Net::Server, it may (or may not) make life easier.
On an additional note, if you are not maintaining connection to the client processes, the suggestions listed above have little validity for you.
my @a=qw(random brilliant braindead); print $a[rand(@a)]; | [reply] |
| [reply] |