From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,958ed45cc4906b53 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-30 09:23:50 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Distributed system portability Date: Mon, 30 Jul 2001 11:57:51 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9k4060$rao$1@nh.pace.co.uk> References: <3B644557.C599A03C@san.rr.com> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 996508672 27992 136.170.200.133 (30 Jul 2001 15:57:52 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 30 Jul 2001 15:57:52 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:10764 Date: 2001-07-30T15:57:52+00:00 List-Id: 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" 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.