Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

using jabber for RPC or inter-server-communication

by schweini (Friar)
on Jul 28, 2003 at 21:59 UTC ( #278639=perlquestion: print w/replies, xml ) Need Help??

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

Hi, beloved members of the Order of St. Larry,

I'm coding this weird system with various servers that from time to time have to send each other messages, but since broadband (or 24/7 connections as such) are hard to get by here, and i'd really rather not go through all this "is the connection up? yes? cool! let's send something to the other server! oops! it's raining! the phonelines drop every 5 minutes, so let's re-send that thing a couple of times!" stuff, i was wondering whether it was feasible to use Jabber (via Net::Jabber, i'd presume) for this - abusing it's ability to send messages to offline users, delivering them when the connection comes up, to an extreme (maybe even for file-transfers).
My idea is that the central server is also a jabber-server, and all the 'sub-servers' are jabber-clients.
i'd also love to send servers command via jabber (like "hey, you! connect to server #5 NOW!", "hey you! what were today's sales?")
has anybody done this before? are there any things i have to watch out for? is this the Right Way To Do Things (tm)?

thanks for any ideas,

- schweini

P.S.: anyone know how to check whether an on-demand pppd conection is up without bringing it up if it isn't?
  • Comment on using jabber for RPC or inter-server-communication

Replies are listed 'Best First'.
Re: using jabber for RPC or inter-server-communication
by zengargoyle (Deacon) on Jul 28, 2003 at 23:15 UTC

    yes and no. with many clients connecting to a single server you still have the problem of the connection to the server going away and your messages getting lost (or raising some sort of lost-connection error).

    a way around this is a bit more work. each client machine also has a local jabber server, these local servers can then forward/communicate between each other. then as long as you can keep the local server running (to recieve messages from the local clients) you'll be ok. the servers can be configured (i think it's default) to queue messages for redelivery if the destination is down at the moment.

    i'm planning to do about the same thing you want to do, i've been waiting for jabberd2 to settle down a bit, for the core protocols to make it through the IETF, and for working Kerberos/SASL Authentication before i make the jump.

      Thanks for not making me feel that alone out here - re-reading my post, the idea of using jabber for this kinda stuff somehow sounded a bit silly in this supposedly golden age of all these weird ways to communicate between machines (SOAP, web services (same thing?), all those RPC modules, ftp, email, etc.).
      Thanks for that pointer - i somehow foolishly assumed that the clients could buffer messages for delivery, too, and thus stand corrected (and whith a sh!tload of more work to do :-).
      didn't know about jabberd2, thanks for that, too...
Re: using jabber for RPC or inter-server-communication
by sauoq (Abbot) on Jul 28, 2003 at 22:19 UTC
    P.S.: anyone know how to check whether an on-demand pppd conection is up without bringing it up if it isn't?

    ifconfig? Something like

    my $ppp_up = system( "ifconfig $ppp_interface | grep UP > /dev/null" ) + == 0;
    perhaps?

    Edit: added redirection to /dev/null.

    -sauoq
    "My two cents aren't worth a dime.";
    
      thanks but no - pppd with the 'demand' option sets up a virtual interface that is 'up' so that applications don't notice that it actually isn't, and then buffers packets, connects, and spurts them out as soon as the connection REALLY is up...
      this is really weird. but then again, i think i saw an option with which you can set which packets bring up the interface, and which don't so maybe if i put ICMP in that thing, i can simply use ping....ah well. let's see.
      thnaks, again...

        thanks but no - pppd with the 'demand' option sets up a virtual interface that is 'up'

        But you can easily see that, because the configured IP adress is a private or invalid (depends on pppd and the configuration, on my gateway it'a a 192.168.) one, while it surely isn't once a connection is established. So checking the ifconfig output, conviniently done using Net::Ifconfig::Wrapper, check the ip-adress for validity/privateness and your done.

        regards,
        tomte


        Hlade's Law:

        If you have a difficult task, give it to a lazy person --
        they will find an easier way to do it.

Re: using jabber for RPC or inter-server-communication
by sgifford (Prior) on Jul 28, 2003 at 23:27 UTC
    Just a random thought...I haven't used Jabber much, but in the past, people have constructed similar systems on top of email or USENET. You might look around for systems like this (USENET's control messages, for example, or FTP-by-mail) for ideas, or consider building on top of one of them.
Re: using jabber for RPC or inter-server-communication
by Anonymous Monk on Jul 29, 2003 at 02:55 UTC
    The project that St.Larry was working on when he started Perl was NNTP ... he'd originally been using BNEWS to queue files for later delivery for split-site source control, IIRC. So using Net::NNTP and friends would be a very Perl solution to queue files for later transmission. Bill N1VUX
Re: using jabber for RPC or inter-server-communication
by aquarium (Curate) on Jul 29, 2003 at 03:35 UTC
    you could use a range of client/servers, e.g. mysql database or postgres if you want triggers, RPC, email, FTP, news, etc. You should think about the characteristics of the connection you want and try to match that to an existing protocol (for the sake of re-use and not having to write your own client/server). That crucial answer will steer you in a particular direction. I'm not sure that a chat server/client is particularly well suited to the transmission of commands, as on a chat session it may not be a big deal if a character gets lost here or there--commands and their parameters must be 100% delivered and executed or 0%. oh well, that's my addition to your salsa.
      yea - i did a RPC-via-mysql prototype once, too, but somehow it felt clumsy, since i had a cronjob checking whether there was anything to do since the last run.
      i'm looking for the most generic/extenable/scalable connection-type out there, that's why i'm looking at jabber (AFAIK it was designed with these goals (but a different application in) mind)
      do you really think that jabber is less reliable than some other form of inter-box communication? as far as i can see, messages either arrive or they don't (i doubt unterminated XML is marked as 'received'), and the risk of a corrupted message seems negiable, i hope.
      am i missing something?
        database like progress has triggers...so when a table gets new data it will spring your procedure into life. good thing about databases is data integrity...if you want to have constraints on a field (say command name), then once you setup your database you don't need extra code...you want to fish out a command used ages ago, no prob, just look in the logs/history table...you want to have distributed architecture with a redundant (live) server, done. If you want no frills RPC then use RPC module, why bother with jabber bloat. no offense to jabber, it's good for what it was made for.
Re: using jabber for RPC or inter-server-communication
by Anonymous Monk on Jul 28, 2003 at 23:44 UTC
    You could try Net::Ping, if you know the host & connection...

       I guess the problem here is that if the interface is down the ping will cause it to come up - forcing the ping to be always true.

       If the pppd has a startup delay and you force ping to only send one or two packets, though, then this approach might work.

       My solution would be to have the 'ifup' script touch a file in /tmp, and the 'ifdown' script remove it.

       Then, barring crashes/weirdness testing the connection status is as simple as testing for the existence of the file in /tmp.

      Steve
      ---
      steve.org.uk

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (3)
As of 2020-10-26 16:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favourite web site is:












    Results (252 votes). Check out past polls.

    Notices?