Re: Advice for simple client/server application

Hello,

On 18 =CE=9D=CE=BF=CE=B5 2012, at 09:04 , Carlo E. Prelz =
<[e-mail]> wrote:

> 	Subject: Advice for simple client/server application
> 	Date: Sun 18 Nov 12 06:09:42AM +0900
>=20
> Quoting Panagiotis Atmatzidis ([e-mail]):
>=20
>> I need to write a client/server application and I'd like to some
>> advice from more experienced users. =20
>>=20
>> There will be multiple clients and one server. Every client should
>> automatically identify to the server and give some details
>> (client_id, date, time, etc). The identification needs to be at very
>> basic level, just to avoid *strange things* from happening, since
>> the server is going to listen on the internet (firewall rules will
>> be applied, but some clients may have dynamic ip's, so some subnets
>> might be able to connect). =20
>>=20
>> The server will dig for data from a database, at each client's
>> request will send an array (list of words) to the client. Then the
>> server will receive a hash with detailed info from the client about
>> the each element of the array and will dump the results into the
>> database. These arrays will be formed only when requested by
>> clients. The server will make sure clients don't get the same arrays
>> and make a check to the given results and that's about it.=20
>>=20
>> It's a fairly simple application. I was thinking of using sinatra +
>> routes, to create the list in 'txt' format to the client but I'm not
>> sure how to send the results back to the sinatra server yet.=20
>>=20
>> So I'd like to ask more advanced users if there's any protocol, gem
>> and/or framework that would make this task easier since I've never
>> done anything similar before. I know there's a variety of protocols
>> which can be used. I'd like to keep things simple & clean as much as
>> possible.=20
>=20
> You do not specify if the clients are also written in Ruby. When I
> have to do inter-process communications, on the same machine or
> between remote machines, I use DRb (Distributed Ruby), which is
> included in MRI. I certainly had to pour some sweat to gain confidence
> with it, but it was worth the effort. You can even set it up to use
> SSL, so the traffic will be encrypted.
>=20
> Let's say you have a server based on this scaffold (engine.rb):
>=20
> =
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
> require 'drb/drb'
> require 'drb/ssl'
>=20
> class Engine
>  HOST=3D'yourhost.xxx'
>  PORT=3D21212
>  URI=3D"drbssl://#{HOST}:#{PORT}"
>  CERTNAME=3D[['C',HOST.split('.')[-1]],['O',HOST],['CN',self.to_s]]
>=20
>  def initialize
>    config=3D{:verbose=3D>false,:SSLCertName=3D>CERTNAME}
>    @srv=3DDRb::start_service(URI,self,config)
>=20
>    #
>    # Your inits
>    #
>=20
>    @para1=3Drand(1000)
>    @para2=3Drand(1000)
>  end
>=20
>  def runme
>    DRb::thread.join()
>  end
>=20
>  #
>  # Remote-callable methdos
>  #
>=20
>  def method1(a)
>    "#{@para1} #{@para2} method 1 returns #{a.to_s}"
>  end
>=20
>  def method2(a)
>    "#{@para1} #{@para2} method 2 returns #{a.to_s} #{a.to_s}"
>  end
>=20
>  def Engine::remote
>    config=3D{:verbose=3D>false}
>=20
>    DRb.start_service(nil,nil,config)
>    DRbObject.new(nil,URI)
>  end
> end
>=20
> if($0=3D=3D__FILE__)
>  Engine::new.runme
> end
> =
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
>=20
> Your client may be something like this:
>=20
> =
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
> require 'engine.rb'
>=20
> class Client
>  def initialize
>    @engine=3DEngine::remote
>  end
>=20
>  def runme
>    puts @engine.method1(rand(1000))
>    puts @engine.method1('test')
>    puts @engine.method2(rand(1000))
>    puts @engine.method2('test')
>  end
> end
>=20
> Client::new.runme
> =
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
>=20
> Your engine can provide an identify method (you may have a hash of
> user ids/passwords associated to one or more address, for
> example). Then, you would have a 'dig' method that would provide the
> desired list of words.
>=20
> For me, DRb has cut the cake several times (you can also base it on
> Unix sockets, for intra-machine communications).=20
>=20
> There are some snags. The biggest is that methods of the DRb-exported
> objects are executed remotely, but if your client receives remote
> objects, it will receive LOCAL COPIES of them. Let's say your engine
> has object @ob, which has method meth. If your engine has this method
>=20
> def m
>  @ob.meth
> end=09
>=20
> meth is executed remotely, by the engine process. But if your
> methods just returns @ob:
>=20
> def m
>  @ob
> end=09
>=20
> and in your client you have
>=20
> ob=3D@engine.m
> ob.meth
>=20
> meth is executed in the client's thread (and thus, for example, it
> won't be able to access the database opened by the remote engine).
>=20
> I hope this is of help.
>=20
> Carlo
>=20
> --=20
>  *         Se la Strada e la sua Virtu' non fossero state messe da =
parte,
> * K * Carlo E. Prelz - [e-mail]             che bisogno ci =
sarebbe
>  *               di parlare tanto di amore e di rettitudine? =
(Chuang-Tzu)
>=20

I'm playing with druby. Some concepts are hard to grasp for now. What =
I'm trying to do is:

1) Send results to server
2) Run some methods with these results from the server
3) Return the values to the server so it can perform the final =
operation.

I don't get how can I get results from the client back to the server...?

How can I send back data to the server? :-/

Thanks

Panagiotis (atmosx) Atmatzidis

email:	[e-mail]
URL:	http://www.convalesco.org
GnuPG ID: 0x1A7BFEC5
gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5
--
The wise man said: "Never argue with an idiot. They bring you down to =
their level and beat you with experience."