Wie kent zo'n RPC server ?

[Verwijderd]

Ik ben al enige tijd op zoek naar het bestaan van een soort RPC (Remote Procedure Call) server voor Unix. Deze zou op basis van een server client model moeten kunnen werken. Het communicatie protocol tussen deze 2 maakt me verder niet zoveel uit. Het zou natuurlijk mooi zijn als dit b.v. op basis van XML zou gaan maar enkel TCP/IP of Unix IPC (enkel lokaal dus) zou ook voldoende zijn.

Het ‘specifieke’ aan deze RPC server (daemon) is dat deze een intern een (console) applicatie kan starten en hiervan de output op aanvraag van de client kan doorgeven. Ook moet deze server nadat hij de applicatie heeft gestart nog input kunnen geven aan dit proces. Deze input is vanzelfsprekend afkomstig van de client. Wat duidelijk niet de bedoeling is dat er een continue verbinding bestaat tussen server / client. De client moet het server proces op afroep kunnen aanspreken informatie uitwisselen en weer kunnen afhaken.

Ik kan me voorstellen dat dit allemaal een beetje vaag overkomt, daarvoor probeer ik even een concreet toepassingsvoorbeeld te gegeven.

Stel, ik geef de RPC server de opdracht (vanaf de client) om b.v. met Mplayer mijn playlist (in console mode) af te spelen. De opdracht is gegeven en vervolgens speelt mplayer mijn muziek zonder dat er noodzakelijkerwijs een client verbonden is met de server. Op een volgend moment wil ik weer een verbinding kunnen maken met de server waarop ik vervolgens de output van Mplayer binnen krijg. Ook moet het mogelijk zijn om opdracht te geven het volgende nummer te spelen (Dit alles mits Mplayer dit normaal gesproken ook ondersteund).

Ik hoop dat mijn voorbeeld wat verduidelijking geeft. Eigenlijk lijkt het geheel wel wat op een screen sessie. Hierbij kan ook Mplayer in een proces worden gestart en kan vervolgens het proces verlaten worden. Hierna kan weer opnieuw de verbinding worden hersteld met de screen sessie en kan er input aan Mplayer worden gegeven. Het verschil hierbij is dat er ‘actieve’ handelingen van de gebruiker nodig zijn en dit (voor zover ik heb kunnen nagaan) biet geautomatiseerd kan worden.

Heeft iemand voor mij suggesties of ideeën dan hoor ik die graag.

[moto-moi]

Het programma 'screen' doet volgens mij precies wat je wilt
Wat heeft RPC er trouwens mee te maken in dit verhaal ?

[Verwijderd]

Hoe ziet de syntax van screen er volgens jou uit om de output van Mplayer (om even bij het voorbeeld te blijven) op te vragen. Of hoe geeft ik de screen sessie vanuit een client input ?

Neem b.v. een php script, hoe zou deze eruit moeten zien ?

code:

$output_mplayer=shell_exec("screen ????");

mischien dat ik met dit voorbeeld nog meer mijn 'probleem' benadruk.

[RvdH]

moto-moi schreef op 09 december 2003 @ 18:13:
Het programma 'screen' doet volgens mij precies wat je wilt
Wat heeft RPC er trouwens mee te maken in dit verhaal ?

Zoals hij al zegt is er voor screen user input nodig.

Maar zoiets wat hij wilt is niet zo moeilijk, je kunt zelf een simpel perl servertje maken die luistert op een poort en commando's uitvoert, deze kan ook de output van deze commando's terugsturen naar de socket van de inkomende verbinding.. 't is dat ik aan het koken ben anders had ik ff een stukje code neergezet.

RPC heeft an sich niks met het probleem te maken zo te zien, maar als term is het wel toepasbaar, remote procedure call, van afstand een procedure uitvoeren..

[ Voor 15% gewijzigd door RvdH op 09-12-2003 18:49 ]

[Verwijderd]

RickJansen schreef op 09 december 2003 @ 18:47:
[...]

Zoals hij al zegt is er voor screen user input nodig.

Maar zoiets wat hij wilt is niet zo moeilijk, je kunt zelf een simpel perl servertje maken die luistert op een poort en commando's uitvoert, deze kan ook de output van deze commando's terugsturen naar de socket van de inkomende verbinding.. 't is dat ik aan het koken ben anders had ik ff een stukje code neergezet.

Ik heb zelf enige tijd geleden geprobeerd om dit zelf te gaan programmeren in C d.m.v. het forken van een applicatie en vervolgens de output wegschrijven naar een file pointer / socket. Ik kwam hierbij echter nogal wat problemen tegen. Ten eerste kan er maar een beperkt aantal bytes worden geschreven naar een socket. Het proces stopt (wacht) op een gegeven moment op een client die deze socket eerst weer moet uitlezen (leeg halen). Dat is meteen het 2e probleem, hierdoor zijn vervolgens de gegevens verloren waardoor het kan gebeuren dat de client op een later tijdstip geen gegevens meer kan uitlezen aangezien deze nog niet is aangevuld door b.v. Mplayer. En het probleem om opnieuw input te geven aan het process heb ik ook nog steeds niet kunnen oplossen. Zelf zat ik te denken aan een extra pipe naar de stdin van het proces.

Als jij zoiets toch denkt te kunnen maken in perl zou dat natuurlijk supper zijn, ik wil alleen ff mijn programmeer ervaringen hierbij delen.

[smokalot]

is t niet mogelijk om screen te automatiseren??? je kunt toch gewoon een .bashrc maken die kijkt of er screen-sessies zijn, en m dan automatisch attached? Of denk ik nu te makkelijk?

(of nog makkelijker, een user "screen -r" als shell geven, als dat kan)

[XTerm]

Uit 'man screen' ...

code:

       -d -m   Start screen in "detached" mode. This creates a new session but
               doesn't  attach  to  it.  This  is  useful  for  system startup
               scripts.

       -S sessionname
            When creating a new session, this option can be used to specify  a
            meaningful  name for the session. This name identifies the session
            for "screen -list" and "screen -r"  actions.  It  substitutes  the
            default [tty.host] suffix.

       -X   Send the specified command to a running screen  session.  You  can
            use  the  -d or -r option to tell screen to look only for attached
            or detached screen sessions. Note that this command  doesn't  work
            if the session is password protected.

[RvdH]

Deze code komt uit `perldoc perlipc`, let met name op de manier waarop het het 'cookie' commando uitvoert.. misschien is dit iets?

Perl:

#!/usr/bin/perl -w
 use IO::Socket;
 use Net::hostent;      # for OO version of gethostbyaddr

 $PORT = 9000;          # pick something not in use

 $server = IO::Socket::INET->new( Proto     => 'tcp',
                                  LocalPort => $PORT,
                                  Listen    => SOMAXCONN,
                                  Reuse     => 1);

 die "can't setup server" unless $server;
 print "[Server $0 accepting clients]\n";

 while ($client = $server->accept()) {
   $client->autoflush(1);
   print $client "Welcome to $0; type help for command list.\n";
   $hostinfo = gethostbyaddr($client->peeraddr);
   printf "[Connect from %s]\n", $hostinfo->name || $client->peerhost;
   print $client "Command? ";
   while ( <$client>) {
     next unless /\S/;       # blank line
     if    (/quit|exit/i)    { last;                                     }
     elsif (/date|time/i)    { printf $client "%s\n", scalar localtime;  }
     elsif (/who/i )         { print  $client `who 2>&1`;                }
     elsif (/cookie/i )      { print  $client `/usr/games/fortune 2>&1`; }
     elsif (/motd/i )        { print  $client `cat /etc/motd 2>&1`;      }
     else {
       print $client "Commands: quit date who cookie motd\n";
     }
   } continue {
      print $client "Command? ";
   }
   close $client;
 }  

[ Voor 8% gewijzigd door RvdH op 09-12-2003 22:47 ]

[sebas]

Wat mij bij je vraag eigenlijk als eerste te binnen schiet is twisted-python.

Met twisted kun je redelijk eenvoudig in een aantal regels een client/server opzetten. Low-level dingen als socket handling zijn daarin al geregeld, ik weet niet of dit is wat je zoek, maar je kan even zelf kijken op:

http://twistedmatrix.com/documents/examples/ (SimpleClient en SimpleServer zijn hier waarschijnlijk een goed begin)

[Verwijderd]

De screen opties die XTerm gaf zijn volgens mij niet voldoende. Wel het starten van een screen sessie kan vanuit een client / script maar dit is niet voldoende. De optie –X klinkt wel oke alleen heb ik dit zelf nog nooit werkend gekregen L. Wat verder rest is het uitlezen van een screen sessie wat volgen mij niet kan.

Ik heb ook nog naar de ‘perldoc perlipc’ code gekeken die RickJansen gaf, maar volgens mij heeft dit verder niet zoveel met het genoemde probleem te maken, dit geld eigenlijk ook voor ‘twisted-python’

[Verwijderd]

meschien gek idee.
maar maak een nieuw gebruiker aan op die "server"
en als die gebruiker start een screen sessie
screen -S blaat
ctrl+a ctrl+d en eruit.
maak dan een scriptje als in
#!/bin/bash
screen -x blaat
en save dat als client-login in je /bin dir ofzo.
open dan passwd als root en verander de standaard shell van die gebruiker in /bin/client-login

dan op je client hoef je enkel maar een ssh sessie te openen naar de server en automaties word je in je screen gedumpt.

dat is toch precies wat je wilt?

[Verwijderd]

Verwijderd schreef op 10 december 2003 @ 12:31:
meschien gek idee.
maar maak een nieuw gebruiker aan op die "server"
en als die gebruiker start een screen sessie
screen -S blaat
ctrl+a ctrl+d en eruit.
maak dan een scriptje als in
#!/bin/bash
screen -x blaat
en save dat als client-login in je /bin dir ofzo.
open dan passwd als root en verander de standaard shell van die gebruiker in /bin/client-login

dan op je client hoef je enkel maar een ssh sessie te openen naar de server en automaties word je in je screen gedumpt.

dat is toch precies wat je wilt?

Dit is idd een hele mooie creatieve oplossing maar het is niet wat ik wil.

Volgens mij kan ik de client nog steeds niet automatiseren. Voor de duidelijkheid de client is GEEN gebruiker maar een proces script of applicatie. Een client (in welke programmeertaal dan ook) kan ik best met deze ‘speciale’ gebruiker een ssh sessie laten openen maar daarna zit het vast. De output van de shell is daarmee nog steeds niet afgevangen, en de client zit waarschijnlijk vast in een ssh sessie. Daarbij kan er ook geen input worden gegeven.

[Verwijderd]

Ik denk, dat als je je beperkt tot non-interactieve commando's (het runnen van een background process, het "skippen" van een mp3 in bijvoorbeeld xmms) dit prima te implementeren is. Hiervoor zou je zelfs gewoon xml-rpc of soap kunnen gebruiken. Dit is gewoon een kwestie van remote applicaties exec()'en, en dat via rpc aansturen.

Interactieve commando's (zoals bijvoorbeeld het "video" scherm van mplayer of de gui van xmms, iig alles wat op X gebaseerd is) gaan niet zo 123 werken (Iig niet, zoals Machiel_22 jij ook al zegt, zonder het nodige kunst en vlieg werk). Neem bijvoorbeeld mplayer. Mplayer is nogal afhankelijk van de geinstaleerde hardware. Voor zover ik weet, kan mplayer alleen hardware aansturen op het systeem waarom mplayer draait. (had je al naar videolan gekeken?) Het is wel mogelijk om mplayer via remote-X te draaien, maar dan ben je de meeste geavanceerde features van mplayer kwijt en is de snelheid ook niet om over te spreken (heb het zelf getest op een 100mbit netwerk). Wat echter wel mogelijk is, denk ik, is om remote text-based applicaties aan te sturen (incl in/output).

[Verwijderd]

Verwijderd schreef op 10 december 2003 @ 13:01:
[...]


Dit is idd een hele mooie creatieve oplossing maar het is niet wat ik wil.

Volgens mij kan ik de client nog steeds niet automatiseren. Voor de duidelijkheid de client is GEEN gebruiker maar een proces script of applicatie. Een client (in welke programmeertaal dan ook) kan ik best met deze ‘speciale’ gebruiker een ssh sessie laten openen maar daarna zit het vast. De output van de shell is daarmee nog steeds niet afgevangen, en de client zit waarschijnlijk vast in een ssh sessie. Daarbij kan er ook geen input worden gegeven.

hoezo zit het daarna vast ?
je hebt dan toch je rechtstreekse verbinding met de server die te ontkoppelen is.

je zou met een simpel perl script al gewoon alles kunnen afvangen en commando's versturen.
zal eens kijken of ik een voorbleedje kan maken.

[Verwijderd]

Verwijderd schreef op 10 december 2003 @ 13:38:
Ik denk, dat als je je beperkt tot non-interactieve commando's (het runnen van een background process, het "skippen" van een mp3 in bijvoorbeeld xmms) dit prima te implementeren is. Hiervoor zou je zelfs gewoon xml-rpc of soap kunnen gebruiken. Dit is gewoon een kwestie van remote applicaties exec()'en, en dat via rpc aansturen.

Als eerder had RickJansen opgemerkt dat het begrip RPC niet echt op zijn plaats is voor dit probleem, ik moet hem daar gelijk in geven. Een goed voorbeeld van een RPC is b.v. de tijd opvragen, er komt een verzoek van een client om de tijd op te vragen. De server start hiervoor het programma ‘date’ en stuurt NADAT het programma date klaar is het resultaat terug. Dit alles heeft echter niks met mijn probleem te maken, om verdere verwarring te voorkomen zal ik dan ook niet meer over een RPC server praten.

Interactieve commando's (zoals bijvoorbeeld het "video" scherm van mplayer of de gui van xmms, iig alles wat op X gebaseerd is) gaan niet zo 123 werken (Iig niet, zoals Machiel_22 jij ook al zegt, zonder het nodige kunst en vlieg werk).

Geen probleem dat hoeft van mij ook niet het gaat mij enkel om programma’s die op de console werken. (Dit kan Mplayer ook)

Neem bijvoorbeeld mplayer. Mplayer is nogal afhankelijk van de geinstaleerde hardware. Voor zover ik weet, kan mplayer alleen hardware aansturen op het systeem waarom mplayer draait.

Geen enkel probleem lijkt me zo.

(had je al naar videolan gekeken?) Het is wel mogelijk om mplayer via remote-X te draaien, maar dan ben je de meeste geavanceerde features van mplayer kwijt en is de snelheid ook niet om over te spreken (heb het zelf getest op een 100mbit netwerk).

Dit heeft niets met mijn probleem te maken, het gaat mij niet speciefiek om Mplayer, ik heb Mplayer slecht als voorbeeld gebruikt. De text editor ee of vi zou ook moeten kunnen.

Wat echter wel mogelijk is, denk ik, is om remote text-based applicaties aan te sturen (incl in/output).

Hier zit hem nu het probleem wat ik al eerder heb omschreven.

[Verwijderd]

Verwijderd schreef op 10 december 2003 @ 13:47:
[...]


hoezo zit het daarna vast ?
je hebt dan toch je rechtstreekse verbinding met de server die te ontkoppelen is.

mmm ik sluit niet uit dat dit niet kan alleen lijkt mij het lastig, licht er natuurlijk aan wat voor een ssh client je gebruikt maar er zal er vast 1 zijn die nadat je hebt geconnect direct weer de verbinding kan verbreken waardoor je hoofd proces niet vast zit. De vraag blijf echter hoe kun je nu de gegevens die de ssh client heeft afgevangen en terugkoppelen naar je proces.

je zou met een simpel perl script al gewoon alles kunnen afvangen en commando's versturen.
zal eens kijken of ik een voorbleedje kan maken.

Kijk dat zou supper zijn, maar verkijk je er niet op zou ik zeggen.

[Verwijderd]

arghh, heb bijna een uur mijn hoofd erop lopen breken door met open2() te werken. maar steeds lukte het password niet.
later erachter gekomen dat dat schijnbaar ook niet mogelijk is

ben daardoor wel op deze module terecht gekomen.
Net::SSH

is een perl module die het allemaal wat makelijker maakt
naast het voorbeeld bevat het ook andere functies om

code:

#!/usr/bin/perl
  use Net::SSH qw(sshopen2);
  use strict;
 
  my $user = "test";
  my $host = "tanzwut";
  my $cmd = "ls";
 
  sshopen2("$user\@$host", *READER, *WRITER, "$cmd") || die "ssh: $!";
 
  while (<READER>) {
      chomp();
      print "$_\n";
  }
 
  close(READER);
  close(WRITER);

in deze manier connect hij, stuurt hij een commando en blijft connected om te uitvoer af te vangen.


punt is wel dat je dan even dsa/rsa key moet maken zodat je password loos kan inloggen op je server.

probleem waar ik nu wel tegenaan hik is dat screen het schijnbaar niet leuk vind om met perl te praten.
(begint te zeuren over het afwezig zijn van een terminal)

maar daar heb ik voor de rest nog niet naar gekeken.
en als screen echt niet mee wilt werken kun je het uiteraard altijd gewoon in bash doen met programma's naar de background sturen.

[Verwijderd]

Ik heb een applicatie gevonden die heel veel overeenkomsten heeft met wat ik voor ogen heb. Deze heet 'mplayerd - mplayer remote control via TCP/IP'. Voor zover ik nu weet werkt het programma met threads en wordt er niet in de code van mplayer gehacked maar wordt deze aangestuurd.

Of de output van mplayer kan worden opgevraagd ben ik nog niet zeker van.

Even een opsomming van de voordelen en nadelen.

Voordelen.

1. Kan de console applicatie (mplayer) in een los proces starten zonder een permanente verbinding met de client.
2. Aansturing kan gedaan worden tijdens het process.

Nadelen.
1. Code is specifiek gericht op mplayer (mijn doel is een willekeurige console applicatie waarvan enkel de client code applicatie afhankelijk is.)
2. Onduidelijk wat er gebeurt met de output.

Verder heeft dit project een mooi toepassingsvoorbeeld van wat de voordelen zijn om het proces los te koppelen van de aansturing/output van de client. Zie hiervoor de webapplicatie (Audible) die los van de server kan opereren. Op de website van mplayerd noemen ze dat een Front End applicatie (mooi term, misschien wel beter dan client).

[Verwijderd]

shopje