how does drb work

[Junkone]

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

 

[Robert Klemme]

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.

Regards

robert

 

[Marc Heiler]

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?

 

[Marcin Raczkowski]

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

 

[ara.t.howard]

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.

a @ http://codeforpeople.com/

 

[Marcin Raczkowski]

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

 

[ara.t.howard]

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.

a @ http://codeforpeople.com/