From: Panagiotis Atmatzidis Date: 2013-06-05T19:56:57+09:00 Subject: Re: TCPServer/Socket and Marshal problem --Apple-Mail=_F1C8F3C4-E767-409C-A97C-74D22260CAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 5 =CE=99=CE=BF=CF=85=CE=BD 2013, at 12:08 , Robert Klemme = wrote: >=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. 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 > 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? 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 > Kind regards >=20 > robert >=20 > --=20 > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/ Best regards, 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=_F1C8F3C4-E767-409C-A97C-74D22260CAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 shortcutter@googlemail.com&= gt; 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.

 
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).


Kind regards

robert

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

Best regards,
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=_F1C8F3C4-E767-409C-A97C-74D22260CAEA--