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

Hello Monks,

I have a problem and I don't really know what to do. The situation is we have a database and the only network interface is to telnet into the box and start a database shell and run statements and either read the output from the screen or save the data to a file and FTP it down. Because the telnet login is very slow I would like to write a daemon that is always logged in and direct encrypted queries through it to the database. I also want the daemon to be logged in about five time and to pass the queries to a idle connection. I think I understand how to code all of it but the passing the information between the free connections. Sorry, I have no code. I am just in the planning stages. Could someone point me at the things I need to be reading? If it makes any difference, the daemon will run on a Fedora Linux box, the database server is AIX, the database is Unidata and daemon written in perl 5.8.3. Any help would be great.

Thanks,
rlb3
  • Comment on Passing client information between multiple sockets...

Replies are listed 'Best First'.
Re: Passing client information between multiple sockets...
by Thelonius (Priest) on May 14, 2004 at 17:01 UTC
    The last time I answered this question, it was for a COBOL application running an HP3000 Image database application, but the principle for a pre-forking server is the same. Here was my response.

    My approach is this

    Have the application start, and open a listen socket

    The application forks to create N children. They thus inherit the listening socket.

    The children run like this: 

         initialize--open files, databases
     send message to parent that we initialized correctly
     while (1) {
       (optional) inform parent we are available
       accept on listen sock
       (optional) inform parent we are busy
       read data
       process transaction
       send response
    }

    [download]
    The parent just monitors the children for unexpected death. It can start a new server if one dies or if the number of available servers falls below some threshold.

    There are a few little details, like how to shut down, making sure you don't get into a loop of restarting a crashing server, etc.

    Your initialization would consist of opening the Telnet connection. The "process transaction" would consist of sending the query to the process's open Telnet session, getting the response and sending data back to the connection.

[reply]
[d/l]
      Note that sending the information to the telnet session and parsing the return information from there is best done by using Expect - it is meant precisely for communicating automatically with ostensibly interactive interfaces.
[reply]
Re: Passing client information between multiple sockets...
by fizbin (Chaplain) on May 14, 2004 at 17:03 UTC
    So, you basically want to implement your own connection pool, and then have a daemon that services incoming queries through one of the available connections out of the pool. This looks like a job for POE. The unfortunate thing is that there's an intimidating amount of background required to start using POE. The fortunate thing is that it's really nowhere near as bad as you fear it's going to be after your first few minutes. 
    --
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/

    [download]
[reply]
[d/l]
Re: Passing client information between multiple sockets...
by Anonymous Monk on May 14, 2004 at 17:08 UTC
    I'm not familiar with Unidata, so please forgive me if I some of what I say here is inapplicable. That said, here's my 30 second brainstorm idea:

    1) Write an implementation of the DBI::Proxy(Server) bits that goes over your telnet interface. This still suffers from the slow-connect problem.

    2) Write (or extend an existing) connection pooling system. This will manage having the slow telnet/database connection done ahead of time and in the background. Depending on how your system works, this might end up being something akin to another DBI::Proxy(Server) pair, where the pool is kept in a server daemon and your application sends its information through that daemon.

[reply]
Re: Passing client information between multiple sockets...
by babel17 (Acolyte) on May 14, 2004 at 19:04 UTC
    This comes up all the time on the expect.pm list. Since you have AIX, put SSH on the database box, then use the expect.pm perl module to spawn an slogin to it from the linux box. Expect.pm can then handle all of the output and response stuff pretty easily. The reason I say use ssh instead of telnet is that automating telnet requires that you save an unecrypted password somewhere. This is a bad idea.
[reply]
      Are you suggestion that he have Expect enter the password to ssh/slogin? Were does Expect store the password? Does it store it encrypted manner? The only thing I can think of would be to use ssh Public Key Authenication and avoid having to enter a password all together thus removing the need for Expect.

      Plankton: 1% Evil, 99% Hot Gas.
[reply]
        I think Expect will be used for more than just automating the login; it'll also interact with the db shell.
[reply]

Back to Seekers of Perl Wisdom