Distributed system portability

Distributed system portability

[Darren New]

Is it generally the case that a distributed system compiled on two
different architectures can talk to itself? In other words, if I write a
distributed system with GNAT, and I compile one portion on Windows and
another portion on Linux, are these two systems likely to talk to each
other? If not, are the stream formats likely to be compatible? If not,
is there a way to redefine the low-level stream operators for things
like Integer to ensure that the same format is used at both ends? Or do
I need to write translation routines to some architecture-independent
format?

I'm basically thinking of something where the clients would be
distributed, talking between themselves peer-to-peer. Does Ada's
portability mean I don't need to write a
translate-to-and-from-network-representation layer, because I can use
streams?

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
       San Diego, CA, USA (PST).  Cryptokeys on demand.
          Only a WIMP puts wallpaper on his desktop.

Re: Distributed system portability

[Pascal Obry]

Darren New <dnew@san.rr.com> writes:

> Is it generally the case that a distributed system compiled on two
> different architectures can talk to itself? In other words, if I write a
> distributed system with GNAT, and I compile one portion on Windows and
> another portion on Linux, are these two systems likely to talk to each
> other? 

No problem with GLADE the GNAT implementation of the distributed Annex. And
this is not theory I've done it :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Distributed system portability

[Frank]

Hi!

How is it with JGNAT, is there a Distributed Annex there?
Has anyone tried to distribute a Ada program so that one partition is a
native executable, and another is running in the JVM?
Can a Ada partition/program/package be recongnized by a Java program as e.g
a class (not using Adept)?

Linux 6.2- Red Hat/GNAT 3-13p.
Frank

Pascal Obry <p.obry@wanadoo.fr> wrote in message
news:uzo9m3kya.fsf@wanadoo.fr...
>
> Darren New <dnew@san.rr.com> writes:
>
> > Is it generally the case that a distributed system compiled on two
> > different architectures can talk to itself? In other words, if I write a
> > distributed system with GNAT, and I compile one portion on Windows and
> > another portion on Linux, are these two systems likely to talk to each
> > other?
>
> No problem with GLADE the GNAT implementation of the distributed Annex.
And
> this is not theory I've done it :)
>
> Pascal.
>
> --
>
> --|------------------------------------------------------
> --| Pascal Obry                           Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --|         http://perso.wanadoo.fr/pascal.obry
> --|
> --| "The best way to travel is by means of imagination"

Re: Distributed system portability

[Pascal Obry]

"Frank" <franjoe@frisurf.no> writes:

> Hi!
> 
> How is it with JGNAT, is there a Distributed Annex there?

AFAIK there is no GLADE for JGNAT project.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Distributed system portability

[Thierry Lelegard]

> Is it generally the case that a distributed system compiled on two
> different architectures can talk to itself? In other words, if I write a
> distributed system with GNAT, and I compile one portion on Windows and
> another portion on Linux, are these two systems likely to talk to each
> other? If not, are the stream formats likely to be compatible? If not,
> is there a way to redefine the low-level stream operators for things
> like Integer to ensure that the same format is used at both ends? Or do
> I need to write translation routines to some architecture-independent
> format?

In pratice, GNAT/GLADE seems to handle this (but I never used it).

In theory (although there is no other implementation of DSA than GLADE),
there is absolutely no guarantee in the ARM about that. Interoperability
is, in my opinion, the biggest hole in Ada95 and writing "open" software
in Ada95 is much harder that it could have been if the default representation
of streams were standardized.

-Thierry
____________________________________________________________________________

Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France
Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
____________________________________________________________________________

Re: Distributed system portability

[Larry Kilgallen]

In article <3B654382.B885CE20@canal-plus.fr>, Thierry Lelegard <thierry.lelegard@canal-plus.fr> writes:
>> Is it generally the case that a distributed system compiled on two
>> different architectures can talk to itself? In other words, if I write a
>> distributed system with GNAT, and I compile one portion on Windows and
>> another portion on Linux, are these two systems likely to talk to each
>> other? If not, are the stream formats likely to be compatible? If not,
>> is there a way to redefine the low-level stream operators for things
>> like Integer to ensure that the same format is used at both ends? Or do
>> I need to write translation routines to some architecture-independent
>> format?
> 
> In pratice, GNAT/GLADE seems to handle this (but I never used it).
> 
> In theory (although there is no other implementation of DSA than GLADE),
> there is absolutely no guarantee in the ARM about that. Interoperability
> is, in my opinion, the biggest hole in Ada95 and writing "open" software
> in Ada95 is much harder that it could have been if the default representation
> of streams were standardized.

When streams go to a file, wouldn't there be a problem with differences
between record-oriented file systems and bag-of-bytes oriented file
systems ?  While the distributed annex may be the topic of this
discussion, some may be more interested in making it possible
for their streams to be interpreted by other languages.

Or is the idea of streams that one should never try to access them
from a non-Ada language ?

Re: Distributed system portability

[Thierry Lelegard]

> When streams go to a file, wouldn't there be a problem with differences
> between record-oriented file systems and bag-of-bytes oriented file
> systems ?

Exactly (I know you are thinking about VMS, which we use as well).
In a file, there is the "logical content" (the data) and the physical
content (the raw content of the blocks of the file). Both are identical
on UNIX but they are not on VMS.

But, anyway, the Ada95 streams only care about the "logical content".
However, even this logical content is non standard. The very first
reason for this is the horrible "type Stream_Element is mod 
implementation-defined" in Ada.Streams. You cannot base interoperability
on an "implementation-defined" feature.

> Or is the idea of streams that one should never try to access them
> from a non-Ada language ?

Yes, for the reason above.

-Thierry
____________________________________________________________________________

Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France
Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
____________________________________________________________________________

Re: Distributed system portability

[Ted Dennison]

In article <3B658765.8F0E0939@canal-plus.fr>, Thierry Lelegard says...
>However, even this logical content is non standard. The very first
>reason for this is the horrible "type Stream_Element is mod 
>implementation-defined" in Ada.Streams. You cannot base interoperability
>on an "implementation-defined" feature.
>
>> Or is the idea of streams that one should never try to access them
>> from a non-Ada language ?
>
>Yes, for the reason above.

I'd say its a bit worse than that. You really shouldn't try to access them from
code that wasn't compiled with the same Ada compiler (unless you are *real*
careful). Even the same compiler on different platforms could give different
results.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Distributed system portability

[tmoran]

>>> Or is the idea of streams that one should never try to access them
>>> from a non-Ada language ?
>
>I'd say its a bit worse than that.  You really shouldn't try to access
>them from code that wasn't compiled with the same Ada compiler (unless you
>are *real* careful).  Even the same compiler on different platforms could
>give different results.
  That's true unless only if (you use default 'read etc) or (the size
of Stream_Element is different).  The former is easily made false and
the latter is rather unlikely to be true, and certainly should not
come as a surprise if you are working with such differing machines.

Re: Distributed system portability

[Ted Dennison]

In article <Rbl97.14918$Kd7.9265254@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>>I'd say its a bit worse than that.  You really shouldn't try to access
>>them from code that wasn't compiled with the same Ada compiler (unless you
>>are *real* careful).  Even the same compiler on different platforms could
>>give different results.
>  That's true unless only if (you use default 'read etc) or (the size
>of Stream_Element is different).  The former is easily made false and
>the latter is rather unlikely to be true, and certainly should not
>come as a surprise if you are working with such differing machines.

That's what I meant by "*real* careful". To make sure they match in a specific
case, you can just try things out and reimplement yourself whatever doesn't work
right because of compiler/target differences. For example, you can implement
your own 'Read, 'Write, 'Input, 'Output, and the streams themselves if need be.
You can check for Ada.Streams.Stream_Element'size and account for that. However,
to make things truly *portable*, so that no such iterative checking is involved,
you have to do *all* this (including implementing all the stream attributes for
*all* types that will ever be used with the stream, excepting perhaps some
composite types). With that much work involved, the streams aren't really
providing you much except the supposedly nice syntax.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Distributed system portability

[tmoran]

>you have to do *all* this (including implementing all the stream attributes for
>*all* types that will ever be used with the stream, excepting perhaps some
>composite types). With that much work involved, the streams aren't really
>providing you much except the supposedly nice syntax.
  (I haven't tried this but ...) I think you just have to implement the
base types, and you need do it only once.  So if you are going to be
doing a lot of systems where data goes between a machine of type A and
another B with different architecture or compiler, you can implement
integer'read etc just once, and all your different programs can use it
for integers ... composite types.  Isn't that in fact done for the
Gnat distributed systems implementation?

Re: Distributed system portability

[Marin David Condic]

That might or might not work, depending on what your requirements are for
the external representation of the data. If you define the whole thing
yourself, then whatever way you output the data is the way you input the
data & defining the operations for the primitive types is (probably) good
enough. However, you *could* be in trouble if there are requirements to
traverse byte boundaries or find things in the middle of words or otherwise
have to do something "wierd". You might also discover that this whole thing
can get rather painful if you have lots of user defined primitive types.

I've seen messages defined in systems that aren't easily dealt with via the
Stream attributes. If you're limiting yourself to a subset of the possible
representations of messages in a stream, you can get by, but if you have to
deal with all of the possibilities it gets complicated.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:QAC97.18171$Kd7.10872006@news1.rdc1.sfba.home.com...
> >you have to do *all* this (including implementing all the stream
attributes for
> >*all* types that will ever be used with the stream, excepting perhaps
some
> >composite types). With that much work involved, the streams aren't really
> >providing you much except the supposedly nice syntax.
>   (I haven't tried this but ...) I think you just have to implement the
> base types, and you need do it only once.  So if you are going to be
> doing a lot of systems where data goes between a machine of type A and
> another B with different architecture or compiler, you can implement
> integer'read etc just once, and all your different programs can use it
> for integers ... composite types.  Isn't that in fact done for the
> Gnat distributed systems implementation?

Re: Distributed system portability

[Ted Dennison]

In article <QAC97.18171$Kd7.10872006@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>
>>you have to do *all* this (including implementing all the stream attributes for
>>*all* types that will ever be used with the stream, excepting perhaps some
>>composite types). With that much work involved, the streams aren't really
>>providing you much except the supposedly nice syntax.
>  (I haven't tried this but ...) I think you just have to implement the
>base types, and you need do it only once.  So if you are going to be

I have actually done some cross-platform (and cross-vendor) stream work. The
approach you mention has the following problems:

a) Not all discrete types are predefined. Integer types need not be derived from
Integer, and then there's modular types and enumerations. I'd particularly
expect to see different sizes used for enumerations. Some compilers might put
small ones in a byte, while others would use whatever their machine word is.

b) 'Output, 'Input, 'Class'Output, and 'Class'Input must deal with discriminants
and unconstrained arrays. The standard says the discriminant/array length has to
be written first, but says nothing about how many bytes are used to do it. The
discriminant should probably get written using its type's 'Write, but there is
no such thing for unconstrained array lengths. Thus you must rewrite 'Input,
'Output, 'Class'Input, and 'Class'Output for all such types (or at least all
unconstrained array types, and the 'Write for all the discriminats on the
discriminated ones).

c) 'Class'Output and 'Class'Input on tagged types also have to deal with the
tag. This is done using Tags.Internal_Tag. You can specify the external tag for
a tagged type, but not the internal tag. Thus in order to write tagged types
portably, you have to provide your own version of 'Class'Output and 'Class'Input
for every tagged type. Among other nasty problems, this involves creating an
algorithm that can come up with a portable unique tag for any type that might
ever get derived from your tagged type. Think on that one for a while...

d) One of the compilers I tried this on would not allow attribute definition
clauses outside of the declarative section that contained the type in question's
definition. That means that any clause for the predefined types would have to be
written in Standard (which you cannot change, as per the standard). I don't know
if this was allowable behavior, required behavior, or a bug.

e) The streams themselves have to be implemented portably (eg: a series of
Ada.Streams.Write's on one outputs the same bit pattern in the same order that
it does on any other). This is mostly only a problem with user-created streams,
as the predefined ones don't seem to leave much room for internal data
manipulation.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Distributed system portability

[Ole-Hjalmar Kristensen]

Ted Dennison<dennison@telepath.com> writes:

> In article <3B658765.8F0E0939@canal-plus.fr>, Thierry Lelegard says...
> >However, even this logical content is non standard. The very first
> >reason for this is the horrible "type Stream_Element is mod 
> >implementation-defined" in Ada.Streams. You cannot base interoperability
> >on an "implementation-defined" feature.
> >
> >> Or is the idea of streams that one should never try to access them
> >> from a non-Ada language ?
> >
> >Yes, for the reason above.
> 
> I'd say its a bit worse than that. You really shouldn't try to access them from
> code that wasn't compiled with the same Ada compiler (unless you are *real*
> careful). Even the same compiler on different platforms could give different
> results.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Yes, in this respect Ada is in reality no better and no worse than C,
regardless of streams and rep clauses.

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: Distributed system portability

[Marin David Condic]

If you are using streams to communicate (perhaps via TCP/IP) between two
processes, you've got some questionable portability problems. The ARM
doesn't give you any guarantees about the representation of things in a
stream - or even that stream elements will be 8 bit bytes, for that matter.
So it is conceivable that what you compile on a PC and what you compile on a
Sun using the same company's compiler may not actually be able to
communicate via this route. You don't get any guarantees that the same
compiler on the same machine in two different releases is going to keep the
representations the same, so you can't even count on that.

That said, one can bring up the practical side of things. It is unlikely
that a compiler is going to change representations of various things
dramatically from one version (or target) to the next without some good
reasons. Its just a whole lot of work to have to change representations or
maintain different representations and who needs that? It also has a habit
of upsetting customers who didn't think much about the non-portability of
this sort of thing. So a practical answer is to determine if the
representations are compatible across the platforms of interest and, if so,
carefully code to that. Isolate the translation from internal to external
form down at a low level so that it is easy to fix. You can take precautions
by overriding the 'Read & 'Write (or 'Input and 'Output) operations so that
you get precise control, but this is possibly creating a bunch of work and
may not fix all your troubles anyway. (Remember, a stream element size is
not guaranteed either, so you've got to work around that as well.)

Now if you go about using the Distributed Systems Annex, that's a different
ball of wax and I'm afraid I've never made use of it to any serious extend &
can't help you there. I seem to recall rumors that it followed some
conventions for doing RPCs that might border on a "standard" and hence they
might be a better way of guaranteeing portability. It all depends on what
your system's requirements are. Can you use RPC's or do you have to blip raw
bytes back & forth?

Now if you have to interface to other systems that might be blipping data up
and down the hose in a clearly defined format, you have just kicked the
complexity up a notch. (*Bam*! :-) There is no easy way to do this except to
roll-your-own WRT getting data into a byte array. If its a fairly fixed set
of messages in the catalog, you at least have the help of representation
clauses on records and Unchecked_Conversion - and that's better than you get
with C, so you're ahead of the game there. If the catalog is large, then
you're hosed because there is no really good way of getting there
automagically from the 'Read, 'Write, 'Input & 'Output operations. You're
going to have to do a lot of work to guarantee representation of every
record type you want to send/receive.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Darren New" <dnew@san.rr.com> wrote in message
news:3B644557.C599A03C@san.rr.com...
> Is it generally the case that a distributed system compiled on two
> different architectures can talk to itself? In other words, if I write a
> distributed system with GNAT, and I compile one portion on Windows and
> another portion on Linux, are these two systems likely to talk to each
> other? If not, are the stream formats likely to be compatible? If not,
> is there a way to redefine the low-level stream operators for things
> like Integer to ensure that the same format is used at both ends? Or do
> I need to write translation routines to some architecture-independent
> format?
>
> I'm basically thinking of something where the clients would be
> distributed, talking between themselves peer-to-peer. Does Ada's
> portability mean I don't need to write a
> translate-to-and-from-network-representation layer, because I can use
> streams?
>
> --
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
>        San Diego, CA, USA (PST).  Cryptokeys on demand.
>           Only a WIMP puts wallpaper on his desktop.

Re: Distributed system portability

[Darren New]

Thanks to *everyone* for the comments. I have much food for thought. :-)

Actually, my plan is as follows:

At each peer, I postulate a single persistant data store holding a
rather complex set of data (primarily file attributes and routing
information, etc.) I also have a client process to talk to each peer and
to its own file store, exchanging data with other file stores.

I have the portable spec for the communication messages, but I was
hoping to defer having to deal with that for a while, in favor of
ensuring that the algorithms will work as I think they will. If I can
make the peer-to-peer stuff look like message passing or calls to
protected objects, then I can layer the procedures that do the
formatting into XML/MIME/BEEP/etc on top once I know it's worthwhile.

Of course, this means I also get to release it earlier, with the
understanding it only interoperates with certain versions of itself to
start.

>  You're
> going to have to do a lot of work to guarantee representation of every
> record type you want to send/receive.

Yeah. In reality, I've already defined the format in MIME and XML. I was
just hoping I wouldn't need to implement the translation from Ada
message sends into text libraries and such until after the rest of the
system started humming.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
          Only a WIMP puts wallpaper on his desktop.