From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-09T02:12:36+09:00
Subject: Re: Considering Ruby For a Networking Application

------=_Part_37643_31349612.1147108353897
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

A great deal depends on what you really need to accomplish. Are you doing a
plain-vanilla protocol handler for some standard server protocol? If your
performance and scalability requirements are low, then the easiest thing is
probably to use blocking i/o with a thread per socket. If you use blocking
i/o, you're better off multiplexing the i/o with a select loop. (My
preference in these cases is ALMOST ALWAYS to avoid a thread pool for a
range of reasons, but most people disagree with me ;-).) If you use
nonblocking i/o, then you really want to avoid multithreading because you'l=
l
need to poll in each one. Ruby can handle it because its implementation of
select is integrated with its internal thread scheduler. (If you try to run
select on a native thread, you'll have major problems with Ruby threads.)

If your process has to do work on other threads, meaning this isn't a pure
server application, then
the calculations change. UDP is really quite a lot easier than TCP, but it
always seems to take some getting used to. So the major questions are: tell
us more about the nature of the application, and tell us what kind of
performance and scalability you need. And additionally, do you need
encryption?


If you decide to look at EventMachine, I can support you if you like. Just
email me or ask questions here. It runs on Windows, works correctly with
Ruby threads, and supports encryption.

------=_Part_37643_31349612.1147108353897--