I am trying to understand how drb works and need some clarificaiton.
DRbServer.start_service nil, method(params)
I then do a client call
DRbClient.start_service
Then how do i trigger the DRbServer so that the mehods is triggered
including a parameter passing.
appreciate help
Please look at the documentation. There is a complete example that explains this. The Pickaxe is also a good source of information.
Regards
robert
On 30.12.2007 02:16, Junkone wrote:
I am trying to understand how drb works and need some clarificaiton.
DRbServer.start_service nil, method(params)
I then do a client call
DRbClient.start_service
Then how do i trigger the DRbServer so that the mehods is triggered
including a parameter passing.
Please look at the documentation. There is a complete example that
explains this. The Pickaxe is also a good source of information.
Well I have the pickaxe, several examples too and use drb optionally to
trigger
compiling and installing packages ... but for some reason, after some
time of not using anything of that... i forget almost everything I read
before about it.
drb usage is either not easy enough IMHO, or underdocumented. What's
also unfortunate is that ... are there other ways for "distributed" ruby
like in a local LAN?
--
Posted via http://www.ruby-forum.com/\.
Marc Heiler wrote:
Please look at the documentation. There is a complete example that
explains this. The Pickaxe is also a good source of information.Well I have the pickaxe, several examples too and use drb optionally to trigger
compiling and installing packages ... but for some reason, after some time of not using anything of that... i forget almost everything I read before about it.drb usage is either not easy enough IMHO, or underdocumented. What's also unfortunate is that ... are there other ways for "distributed" ruby like in a local LAN?
DRb documentation is mostly either bad, or for experts.
Basically DRb.start_service should be used for either starting client or server - which is strange already.
now run DRbServer.new("strange://usrl", object) starts drb server.
and @object = SRbObject.new(nil, "strange://url") creates object in client
now each method call to @object is marshaled and sent to DRBServer, where it's executed, and results is again marshaled and sent back.
have phun
Basically DRb.start_service should be used for either starting client or server - which is strange already.
just to clarify: not really. all drb processes are servants. neither server nor client exist separately. the definitions are determines dynamically based on usage.
now run DRbServer.new("strange://usrl", object) starts drb server.
and @object = SRbObject.new(nil, "strange://url") creates object in client
you have to start_service in both, perhaps with a front object and perhaps not. when you look up and object using DRbObject service is started for you iff it's not already on. the reason is that DRb supports blocks. consider:
remote_array = DRbObject.new nil, "druby://localhost:1234"
remote_array.each do |element|
element.upcase!
end
if you think about this for a bit you'll see a complex interaction between two servants. first, "remote_array.each" is going to make a call on a remote object. that call is going to be passed a *block* but, wait a minute, blocks cannot be marshaled so how does that work? it doesn't. the block stays on the "client" and is executed on that machine, on that cpu - but with a handle on remote "element" objects. depending on how those objects are setup they might be objects which are totally dumped/copied to the client and therefore changes are going to be local *or* they may be proxies on remote objects and destructive methods might actually change the remote object behind the proxy. see DRbUndumped for more on this.
in any case the first step to understanding drb is doing away with the idea of static servers and clients - in drb every machine can potentially be both, sometimes within a given method. the distribution contains a *ton* of examples:
cfp:~/build/ruby-1.8.6/sample/drb > ls
README.rd dbiff.rb dhasen.rb dqin.rb drbc.rb drbs-acl.rb extserv_test.rb holderc.rb name.rb rindac.rb ring_place.rb
README.rd.ja dcdbiff.rb dhasenc.rb dqlib.rb drbch.rb drbs.rb gw_ct.rb holders.rb namec.rb rindas.rb simpletuple.rb
darray.rb dchatc.rb dlogc.rb dqout.rb drbm.rb drbssl_c.rb gw_cu.rb http0.rb old_tuplespace.rb ring_echo.rb speedc.rb
darrayc.rb dchats.rb dlogd.rb dqueue.rb drbmc.rb drbssl_s.rb gw_s.rb http0serv.rb rinda_ts.rb ring_inspect.rb speeds.rb
which is a great place for people get started.
btw: favourite way to use drb is for ipc between two processes on the same machine via:
process a:
DRb.start_service "druby:localhost:0", some_object_that_acts_as_a_server
uri = DRb.uri
process b:
DRb.start_service "druby:localhost:0"
remote_object = DRbObject.new nil, uri
by starting service this way you basically setup drb to function perfectly for ipc situations and accept connections on all interfaces. it turns out that using remote/localhost objects for ipc is a portable way to accomplish something that's generally non-portable on windows/unix/whatever. recently i used this
http://drawohara.com/post/22540307
to solve a sticky windows signal issue - took only 4 or 5 lines of code. really good stuff that drb 
cheers.
On Dec 30, 2007, at 8:31 AM, Marcin Raczkowski wrote:
--
share your knowledge. it's a way to achieve immortality.
h.h. the 14th dalai lama
Don't get me wrong, I like drb, but as you said it's complex, and people usually want simple solutions 
I even used drb as lock that would not allow program to be run if another instance was running
require 'drb'
begin
DRbServer.new("drb://localhost:23422",nil)
rescue Exception
puts "only once!"
exit 1
end
but that doesn't change the fact that it's often confuising, blocking, have some memory problems, and it's slow
Don't get me wrong, I like drb, but as you said it's complex, and people usually want simple solutions
conceded. ever check out romp?
I even used drb as lock that would not allow program to be run if another instance was running
require 'drb'
begin
DRbServer.new("drb://localhost:23422",nil)
rescue Exception
puts "only once!"
exit 1
end
that's very clever and i'm sure i'll use it one day soon!
but that doesn't change the fact that it's often confuising, blocking, have some memory problems, and it's slow
i haven't seen blocking issues - but i rarely touch windows so i expect that's the issue. speed hasn't been an issue for me but that's because my uses have had zero performance requirements. the romp site, old as it may be, claimed to be much faster.
kind regards.
On Dec 30, 2007, at 10:44 AM, Marcin Raczkowski wrote:
--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama