Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Subject: RE: [MINA] and readiness selection
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Jul 2005 10:50:38 -0500
Content-class: urn:content-classes:message
Message-ID: <79649FBBF123C141BA6BD4D4B132513506D67B@mail.starthis.com>
Thread-Topic: [MINA] and readiness selection
Thread-Index: AcWM9/HWzgM/gdyKRdedWAGyNXeGcQEODoDg
From: "Bharath Sundararaman" <Bharath.Sundararaman@starthis.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>

Hi Niclas,

Do you have any example code where MINA sends/receives data from a PLC?
I'm trying to use Ethernet/IP (CIP over Ethernet) to talk to PLCs in
vain.

Bharath.

-----Original Message-----
From: Niclas Hedhman [mailto:niclas@hedhman.org]=20
Sent: Wednesday, July 20, 2005 1:55 AM
To: Apache Directory Developers List
Subject: Re: [MINA] and readiness selection

On Wednesday 20 July 2005 02:34, Bharath Sundararaman wrote:
> Scenario 2
> I have an application that does asynchronous reads and writes to
devices
> (e.g. PLC) via ethernet/ip.=20

> So, communication with the device happens using a SelectableChannel
(tied
> to the device's IP address) which registers with a selector for
read/write
> interest and when data has to be read from a device, a read event is
pushed
> onto a queue, selector is woken up and read happens. There could be
many
> reads happening at the same time or alternate reads and writes in a
totally
> ad-hoc fashion. Is MINA a good choice for this scenario where you send
and
> receive bytes of data to devices?

I don't think this is any more unique to MINA than for normal sockets.
You=20
would always need to provide the scheduler of request/response pairs,
and the=20
algorithm of how much concurrency can occur over the same port, which is

probably defined by the devices. My guess is that most PLCs will only
allow=20
one request for connection, which also makes the scheduler on the
"client"=20
simpler.

For real high perfomance communication subsystems to PLCs, it is likely
that=20
you will need a 3 stage SEDA architecture, where the you have an Encode,

Communicate and Decode stage independently chewing away at their
respective=20
parts. And in that fashion, it seems to me MINA fits the bill well.


If PLCs are "your daily bread", then I would like to advertise a just
started=20
project of OpenHMI.org, which will look into developing the HMI side of
the=20
equation. This effort is not yet started, mainly awaiting the holiday
seasons=20
in Sweden to finish.

Cheers
Niclas