* Glade :- he distributed Annex @ 2002-04-03 14:26 Pedro Menendez 2002-04-04 17:48 ` Toshitaka Kumano 0 siblings, 1 reply; 5+ messages in thread From: Pedro Menendez @ 2002-04-03 14:26 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Glade :- he distributed Annex 2002-04-03 14:26 Glade :- he distributed Annex Pedro Menendez @ 2002-04-04 17:48 ` Toshitaka Kumano 2002-04-05 14:15 ` Ted Dennison 0 siblings, 1 reply; 5+ messages in thread From: Toshitaka Kumano @ 2002-04-04 17:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Glade :- he distributed Annex 2002-04-04 17:48 ` Toshitaka Kumano @ 2002-04-05 14:15 ` Ted Dennison 2002-04-05 16:20 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 5+ messages in thread From: Ted Dennison @ 2002-04-05 14:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Glade :- he distributed Annex 2002-04-05 14:15 ` Ted Dennison @ 2002-04-05 16:20 ` Ole-Hjalmar Kristensen 2002-04-05 22:05 ` Ted Dennison 0 siblings, 1 reply; 5+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-05 16:20 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Glade :- he distributed Annex 2002-04-05 16:20 ` Ole-Hjalmar Kristensen @ 2002-04-05 22:05 ` Ted Dennison 0 siblings, 0 replies; 5+ messages in thread From: Ted Dennison @ 2002-04-05 22:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-04-05 22:05 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-04-03 14:26 Glade :- he distributed Annex Pedro Menendez 2002-04-04 17:48 ` Toshitaka Kumano 2002-04-05 14:15 ` Ted Dennison 2002-04-05 16:20 ` Ole-Hjalmar Kristensen 2002-04-05 22:05 ` Ted Dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox