Glade :- he distributed Annex

Glade :- he distributed Annex

[Pedro Menendez]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 353 bytes --]


I have worked with Glade for a University work and new questions arise to me:

are there any restrictions regarding the communication in a distributed 
application. I mean clients and server/s on the same LAN and the such. This is 
the case in MPI, isn't it?

thanx in advance

Pedro Men�ndez
Oviedo (Spain)
http://petra.euitio.uniovi.es/~i1641014

Re: Glade :- he distributed Annex

[Toshitaka Kumano]

Hi,

Pedro Menendez wrote:
> are there any restrictions regarding the communication in a distributed
> application. I mean clients and server/s on the same LAN and the such. 

As far as I understand, no restriction such as "same LAN", if you mean
"same segment". 
And different segments could be linked by adding appropriate routing ?

Glade just requires the TCP connection is stable, and, of course,
unstable network, by such as a congested router or by ethernet with 
many collisions, could introduce some instability to a Glade application,
if you don't consider some recovery mechanism in your design of the
application.

The distribution annex, a sophisticated RPC, is one thing, and the fault
tolerance of transport layer underlying it is another matter.

In other malicious words, I consider Glade by itself could not be
used for practical, fault tolerant or real-time (deterministic response)
application. This can be "restriction" in your application domain.


> This is the case in MPI, isn't it?

I don't think so. TCP/IP based MPI implementations don't have
such restrictions.

MPI, in its strict meaning, is just a standard (paper) of API and
protocol of presentation/session layer, and the standard says nothing
about its lower layer of implementation. So answer to your question is
"it depends".

For example, our proprietary implementation of MPI is directly
on the link layer of our in-house bus,  without TCP/IP protocol stack,
aimed only for performance, without any routing capability.
In this case, the applications can talk only if they are on "same bus".

-- 
Toshitaka Kumano

Re: Glade :- he distributed Annex

[Ted Dennison]

Toshitaka Kumano <kumano@cl.cilas.net> wrote in message news:<mailman.1017942482.19817.comp.lang.ada@ada.eu.org>...
> In other malicious words, I consider Glade by itself could not be
> used for practical, fault tolerant or real-time (deterministic response)
> application. This can be "restriction" in your application domain.

Considering that TCP itself can't be used for that kind of real-time
application (and IP itself can't either, except under certian
circumstances), that's a pretty safe statement.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Glade :- he distributed Annex

[Ole-Hjalmar Kristensen]

dennison@telepath.com (Ted Dennison) writes:

> Toshitaka Kumano <kumano@cl.cilas.net> wrote in message news:<mailman.1017942482.19817.comp.lang.ada@ada.eu.org>...
> > In other malicious words, I consider Glade by itself could not be
> > used for practical, fault tolerant or real-time (deterministic response)
> > application. This can be "restriction" in your application domain.
> 
> Considering that TCP itself can't be used for that kind of real-time
> application (and IP itself can't either, except under certian
> circumstances), that's a pretty safe statement.
> 
> 
> -- 
> T.E.D.
> Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
> Homepage -  http://www.telepath.com/dennison/Ted/TED.html

On the other hand UDP/IP is perfectly good enough to run fault tolerant 
*soft* real time systems in a workstation cluster. In other words, good enough 
for a telephone company, but don't try running your engine controller on it.

For building a fault tolerant networked application, you don't really need a 
reliable transport protocol, what you need is a reliable indication of a node 
or network error.

A "reliable" transport protocol usually only gets in your way by insisting 
that everything is fine until it at last admits that it cannot deliver 
your message. Then you have to handle the error yourself anyway.

Having spent the last years working on such a beast in C++ (a soft
real-time, fault-tolerant, scalable RDBMS), it would be very
interesting to see if Glade could be used for such applications. A
quick guesstimate tells me that there would be great savings both in
terms of readability, maintainablity, and code volume (at least a
factor of 2 for some modules) by using Ada threads and Glade instead
of the homegrown RPC-like mechanism and extremely primitive (but fast)
thread system we used.

Btw., I've been trying to get Glade to run under Windows 2000, but when running 
gnatdist, gcc complains that the distribution feature is not supported.
This is Glade 3.14p, with ditto GNAT. I used Cygwin to build Glade, 
apparently with no errors.

Any suggestions?

Re: Glade :- he distributed Annex

[Ted Dennison]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> wrote in message news:<7vit76kth4.fsf@vlinux.voxelvision.no>...
> dennison@telepath.com (Ted Dennison) writes:
> > Considering that TCP itself can't be used for that kind of real-time
> > application (and IP itself can't either, except under certian
> > circumstances), that's a pretty safe statement.

> On the other hand UDP/IP is perfectly good enough to run fault tolerant 
> *soft* real time systems in a workstation cluster. In other words, good enough 
> for a telephone company, but don't try running your engine controller on it.

Mostly. As I alluded to, it *can* be used for hard real-time, under
some very specific circumstances (dedicated direct link, with no other
applications using it, no outside traffic forwarded onto it, and a RT
IP stack). The main non-determinisim in IP comes in with the
collision/retry mechanisim, and with routing issues. We did this with
the last simulator I worked on. It allowed us to use a well-known API,
and industry standard PC's. It would have made the whole thing damn
cheap, if it weren't for the >$200K of custom hardware we had to
drive. :-)


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html