From: Panagiotis Atmatzidis Date: 2013-06-05T22:27:06+09:00 Subject: Re: TCPServer/Socket and Marshal problem --Apple-Mail=_BB767A0A-7834-4D0E-884E-62E14AEDEE92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-7 On 5 =C9=EF=F5=ED 2013, at 14:53 , Robert Klemme = wrote: >=20 >=20 >=20 > On Wed, Jun 5, 2013 at 12:56 PM, Panagiotis Atmatzidis = wrote: >=20 > On 5 =C9=EF=F5=ED 2013, at 12:08 , Robert Klemme = wrote: >=20 >>=20 >>=20 >>=20 >> On Wed, Jun 5, 2013 at 10:54 AM, Panagiotis Atmatzidis = wrote: >> =20 >> Second approach was DRuby, but you can't have bi-directional = communication in DRuby without turning the client into a server, which = requires opening another port and this in a real-case scenario won't cut = it for me. >>=20 >> That depends on how you set it up: if avoiding that other port is so = important you could have a queue on client side which is read from the = server in an endless loop. Whenever the queue is empty the call blocks. = Yeah, I know, ugly workaround. >=20 > I spent two days trying to find a *normal way* to return the object to = the server. Didn't see that sort of solution nowhere online. >=20 > Are you saying you need an example to implement that? > =20 >> TCPServer/Socket seems a lot cleaner + I have the chance of learning = one thing or two about how a client/server app works at this level. = Since time is not an issue and learning as much as possible on the = process is one of the goals, all I need to do (in my case) is ti = implement 'MuTex' and handle TCPServer/Socket connection errors in a = graceful way and I'm on. >>=20 >> Fair enough. What is your application supposed to do? >=20 > Client auth's to the server, using just an string. If auth = successfully client requests an object, performs actions and returns an = object with results of these actions. Both objects are arrays (text). >=20 > And where in that scenario is the server issuing requests towards the = client? I only see >=20 > client connects and obtains entry object > client invokes session =3D entry.authenticate(credentials) > server returns session object (if auth successful) > client invokes data =3D session.get_whatever_i_need() > client invokes result =3D data.do_the_work() (locally) > client invokes session.the_result_is(result) > client invokes session.close (optional) You mean this code is possible? https://gist.github.com/atmosx/5713828 = (look at the run method) So the client can dump the results to the remote database? Or pass it to = the server to make the check ups and then dump it to the database? I missed that part :-P if that's the case.=20 >=20 > Cheers >=20 > robert >=20 > --=20 > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/ Panagiotis (atmosx) Atmatzidis email: atma@convalesco.org 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." --Apple-Mail=_BB767A0A-7834-4D0E-884E-62E14AEDEE92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-7 shortcutter@googlemail.com&= gt; wrote:



On Wed, Jun 5, 2013 at 12:56 PM, Panagiotis = Atmatzidis <atma@convalesco.org> wrote:

On 5 =C9=EF= =F5=ED 2013, at 12:08 , Robert Klemme <shortcutter@googlemail.com> wrote:




On Wed, Jun 5, = 2013 at 10:54 AM, Panagiotis Atmatzidis <atma@convalesco.org> wrote:
 
Second approach was DRuby, but you = can't have bi-directional communication in DRuby without turning = the client into a server, which requires opening another port and this = in a real-case scenario won't cut it for me.

That depends on how you set it = up: if avoiding that other port is so important you could have a queue = on client side which is read from the server in an endless loop. =  Whenever the queue is empty the call blocks.  Yeah, I know, = ugly workaround.

I spent two = days trying to find a *normal way* to return the object to the server. = Didn't see that sort of solution nowhere = online.

Are you saying you need an example to = implement that?
 
TCPServer/Socket seems a lot cleaner + I have the chance of = learning one thing or two about how a client/server app works at this = level. Since time is not an issue and learning as much as possible = on the process is one of the goals, all I need to do (in my case) is ti = implement 'MuTex' and handle TCPServer/Socket connection errors in = a graceful way and I'm on.

Fair enough.  What is your application = supposed to do?

Client = auth's to the server, using just an string. If auth successfully client = requests an object, performs actions and returns an object with results = of these actions. Both objects are arrays (text).

And where = in that scenario is the server issuing requests towards the client? =  I only see

client connects and obtains entry object
client invokes session =3D = entry.authenticate(credentials)
server returns session object (if auth successful)
client invokes data =3D = session.get_whatever_i_need()
client invokes result =3D data.do_the_work() = (locally)
client invokes = session.the_result_is(result)
client invokes session.close = (optional)

You mean this = code is possible? https://gist.github.com/at= mosx/5713828 (look at the run = method)

So the client can dump the results to = the remote database? Or pass it to the server to make the check ups and = then dump it to the database?

I missed that = part :-P if that's the case. 


Cheers

robert

--
remember.guy do |as, often| as.you_can - without = end
http://blog.rubybestpractices.= com/

atma@convalesco.org
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."

= --Apple-Mail=_BB767A0A-7834-4D0E-884E-62E14AEDEE92--