Re: Hilfe: DRb/TupleSpace - Problem

hallo clemens,


> na, jetzt kannste bitte auch erklaeren, wie das funktioniert.  wenn
> ich referenz lese, denke ich zeiger.  wenn ich zeiger lese, denke ich
> erst sehr viel spaeter an strukturinformation, und ausserdem muessen
> alle, die einen zeiger benutzen, vorher schon wissen, worauf der
> ueberhaupt zeigen soll!

referenz und zeiger sind auch fuer mich das gleiche. allerdings sollte
man zeiger nicht sofort mit "adresse im ram meines computers"
(C-sichtweise) gleichsetzen, sondern eher mit "objekt, dass ein anderes
objekt identifiziert und ich kenne jemanden der sich diese zuordnung
merkt". referenz meint in diesem fall proxy-objekt - dazu gleich mehr.
bei drb laeuft das - soweit ich das mitbekommen habe; im prinzip wird es
wohl stimmen - so ab:


da lauscht ein server an einem port darauf, ob sich ein client meldet. ist
dem so, so liefert er diesem - scheinbar - das objekt, das dem server beim
start zu diesem zweck mitgegeben wurde, in meinem fall ein
tuplespace-objekt.

server:
        require 'drb'
        require 'tuplespace'
        require 'thread'

        port = 8888
        DRb.start_service("druby://localhost:#{port}", TupleSpace.new)
        puts "Tuple space server runs at #{DRb.uri}\n"
        DRb.thread.join



client:
        require 'drb'
        require 'tuplespace'

        DRb.start_service
        tuple_space = DRbObject.new(nil, "druby://localhost:8888")

        class Dummy
                include DRbUndumped

                def initialize
                end
        end

        s = Dummy.new
        tuple_space.out [s]


dieses vom server "geschickte" objekt kann dann verwendet werden, als
waere es tatsaechlich beim client. da man sich darum also keine gedanken
machen muss (bzw. muessen sollte) heisst mein objekt beim client auch
nicht (eigentlich korrekter) tuple_space_proxy sondern einfach
tuple_space.
  statt also direkt das tuplespace-objekt vom server zum client zu
verschicken wird auf der client-seite nur ein objekt erzeugt, dass sich so
verhaelt, als waere es das tuplespace-objekt von der server-seite. dieses
stellvertreter-objekt (proxy) reagiert eigentlich nur auf eine methode,
method_missing, welche ruby an objekte verschickt, die eine meldung
bekommen haben, die sie nicht implementieren. daraufhin nimmt der poxy den
fehlgeschlagenen methodenaufruf und reicht ihn an den server weiter. dort
existiert ja das tuplespace-objekt und dieses kann die nachricht verarbeiten.
das ergebnis wird wieder zurueck geschickt.
  dieses hinschicken von methodenaufrufen (samt parameter) und das
zurueckschicken des ergebnisses verlaeuft nun so, dass die
beteiligten objekte (parameter, rueckgabewert) serialisiert und ueber die
client-server-verbindung geschickt werden. auf der anderen seite werden
sie dann wieder (als kopie) instanziiert - sofern eine passende
klassendefinition vorhanden ist.
  mit dem "include DRbUndumped" man kann allerdings auch erzwingen, dass
solch ein objekt nicht serialisiert wird, sondern ebenfalls durch einen
proxy beim server dargestellt wird. die im obigen code erzeugten objekte
sind daher wie folgt verteilt:

        client                  server
        ----------              ----------
        tuplespace-proxy        tuplespace
        dummy                   dummy-proxy


        client                  server
        -----------             ----------
        tuplespace-proxy        tuplespace
        dummy                   kopie von dummy

in meinem fall war es mir nun ziemlich egal war, wo die eigentlichen
objekte hausen (ob beim server oder beim client). wichtiger war, das ich
in den server-code nicht die klassendefinitionen von den objekten
aufnehmen muss, die ich in den tuplespace ablegen moechte.


ach so ja: diese proxy-objekte kann man natuerlich als eine art zeiger
bzw. referenz auf das vertretene objekt betrachten, hauptsache jeder proxy
kennt sein objekt.


so, ich hoffe, ich hab dir jetzt nicht was erzaehlt, was du gar nicht
gefragt hast...

bye,

        patrick