Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Simple TCP server recomendations

by Random_Walk (Parson)
on Oct 02, 2006 at 13:11 UTC ( #575871=perlquestion: print w/ replies, xml ) Need Help??
Random_Walk has asked for the wisdom of the Perl Monks concerning the following question:

Greetings honoured monks

I have a client daemon that will be distributed to a (reasonably large) number of machines on our internal network. I need a way to remotely interogate the client for its logfiles, current version etc (this requirement is likely to expand to other methods too). I also need to be able to send it updated config files and updates to the code base. It has to be multi-platform (aix, linux, win32).

I am thinking of a simple server listening on the client and passing requests recieved to subs. Where it need to download stuff I will have it connect to a hardcoded server name to look for and grab a new version (we have control of the DNS).

  • Does my approach sound sane
  • a maze of twisty server modules ....
    • SOAP::Lite
    • Net::Server
    • Net::EasyTCP
    • Net::Server::NonBlocking
    • NetServer::Generic
I have the feeling I could spend the rest of this week reading CPAN module POD and still not really be enlightenend. Any of the above recomended or did I miss your favourite ? Is it really worth the learning curve of POE ? I don't want to start developing to some module that turns out to be broken, abandoned or buggy on one platform.

Many thanks for your time and experience,
R.

Pereant, qui ante nos nostra dixerunt!

Comment on Simple TCP server recomendations
Re: Simple TCP server recomendations
by jasonk (Parson) on Oct 02, 2006 at 15:31 UTC

    The learning curve for POE isn't really that big if you start with a simple problem like this. Here is a simple little POE-based script that can give you an easily expandable REST-style http interface for doing the kinds of things you want to do...

    In this little server, the uri path that is requested just gets turned into a sub name (so a request for /version becomes _version), and if that sub exists, then it's output is returned as the HTTP response. This way you can add new features just by adding new subroutines.

    Update: merlyn is right, I oversimplified a little while posting this, and a little more care should be taken with the functions you expose to this type of application. I added "remote_request" to the beginning of any functions that are accessible from the web interface to mitigate this.


    We're not surrounded, we're in a target-rich environment!
      While your goal of making it easily extensible is admirable, this line troubles me:
      if ( ! defined &$path ) {
      Since you don't force any particular content on $path (except that it be strictly alphanumeric), you're also exposing any miscellaneous subroutines that happen to be defined. Are you sure that everything that POE exports is safe to be invoked, for example?

      A better strategy would be to narrow the namespace a bit:

      $path = "remote_request_$path"; ...
      which ensures that someone has to go to the trouble to name a subroutine a particular shape before it can be invoked.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        That's a very good point, I had distilled this down from an application very similar to what the OP was looking for that I was actually using in production, and may have oversimplified it a bit.

        In the original, I was using attributes to flag subs that should be accessible through this interface, and didn't want to confuse the posting by leaving in all the attribute-related code. I had been thinking that it was unlikely that POE was exporting any functions that started with an underscore, but on further reflection it would certainly be possible to invoke random methods that didn't start with an underscore by hand-crafting your requests, although the amount of damage you could do would be limited by not being able to pass arguments to any of those methods, it is still something to keep in mind.


        We're not surrounded, we're in a target-rich environment!
Re: Simple TCP server recomendations
by zentara (Archbishop) on Oct 02, 2006 at 16:01 UTC
    I like Net::EasyTCP, although I can't say that I tested the other choices. Why? It takes care of security( encryption, and port passwords); and it takes care of serializing hashes automatically, so you can pass hashes through the socket, without having to hassle with serializing.

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: Simple TCP server recomendations
by HeatSeekerCannibal (Beadle) on Oct 02, 2006 at 21:46 UTC
    I have been using Net::Daemon with Config::IniFiles....and ended up needing exactly what you're looking for. Net::Daemon is good for handling simultaneous connections, but it would be nice if it could be combined with something like Net::EasyTCP.
    Heatseeker Cannibal
Re: Simple TCP server recomendations
by abell (Chaplain) on Oct 03, 2006 at 11:26 UTC
    My favourite for network communications is Frontier::RPC2, implementing XML RPC. It's quite easy to set-up compared to SOAP solutions and has all the expressive power I have needed so far.

    Cheers

    Antonio


    The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://575871]
Approved by McDarren
Front-paged by diotalevi
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (6)
As of 2014-08-31 11:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (294 votes), past polls