adasockets and adatypes

adasockets and adatypes

[Tony Gair]

Does anyone know a way of sending an adatype (especially a record of string and enumerated types) down a socket so it can be received by another ada program which recognises the type....

Regards
Tony Gair

Re: adasockets and adatypes

[David C. Hoos, Sr.]

Yes.

Make the record a tagged type, and use 'Output to send it
and 'Input to read it.

The External_Tag of the tagged type will be sent first,
so that the receiver can determine its type.

You will need to use the Stream operations of adasocketa.

----- Original Message -----
From: "Tony Gair" <tonygair@blueyonder.co.uk>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: September 04, 2001 5:53 AM
Subject: adasockets and adatypes



Does anyone know a way of sending an adatype (especially a record of string
and enumerated types) down a socket so it can be received by another ada
program which recognises the type....

Regards
Tony Gair
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: adasockets and adatypes

[Florian Weimer]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

>> Does anyone know a way of sending an adatype (especially a record of string
>> and enumerated types) down a socket so it can be received by another ada
>> program which recognises the type....

> Make the record a tagged type, and use 'Output to send it
> and 'Input to read it.

This works only if the compiler and architecture are the same on both
ends of the communication channel.

Re: adasockets and adatypes

[David C. Hoos]

----- Original Message -----
From: "Florian Weimer" <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, September 04, 2001 7:17 AM
Subject: Re: adasockets and adatypes


> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
>
> >> Does anyone know a way of sending an adatype (especially a record of
string
> >> and enumerated types) down a socket so it can be received by another
ada
> >> program which recognises the type....
>
> > Make the record a tagged type, and use 'Output to send it
> > and 'Input to read it.
>
> This works only if the compiler and architecture are the same on both
> ends of the communication channel.


This is simply not so. If the record component types have user-defined
endianness-independent stream attributes, then the data will have the
same format on the network.  Further, if you have compilers that do not
produce identical External_Tags, then a representation clause on the
type will insure that the External_Tags are identical.

I am communicating between Intel and Sun machines every day, in this
way.

To be sure, if one does an incomplete job of defining the types, then
there are no guarantees of identical stream representaion -- but the
language
_does_ provide the means doing the job the original poster requested.

> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: adasockets and adatypes

[Ted Dennison]

In article <mailman.999615244.13142.comp.lang.ada@ada.eu.org>, David C. Hoos
says...
>This is simply not so. If the record component types have user-defined
>endianness-independent stream attributes, then the data will have the

How does one do this for language-defined types? Every Ada compiler I've tried
it on (including gnat 3.13p just now) only allows one to redefine the IO
attributes in the same declaration section in which the type is declared.

If you only have 2 implementations to get talking, it is fairly easy to massage
one end until it talks like the other. That isn't the same thing as true
portability. 

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

Re: adasockets and adatypes

[David C. Hoos]

----- Original Message -----
From: "Ted Dennison" <dennison@telepath.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, September 04, 2001 10:33 AM
Subject: Re: adasockets and adatypes


> In article <mailman.999615244.13142.comp.lang.ada@ada.eu.org>, David C.
Hoos
> says...
> >This is simply not so. If the record component types have user-defined
> >endianness-independent stream attributes, then the data will have the
>
> How does one do this for language-defined types? Every Ada compiler I've
tried
> it on (including gnat 3.13p just now) only allows one to redefine the IO
> attributes in the same declaration section in which the type is declared.

One can't.  That's why when stream format is important, one should define
his own
types -- although I've never found a reason not to use the language-defined
type
String -- since I've only dealt with machines in which the sizes of
characters
and stream elements have been identical -- i.e., 8.

>
> If you only have 2 implementations to get talking, it is fairly easy to
massage
> one end until it talks like the other. That isn't the same thing as true
> portability.
I agree. one should define what the stream should look like from the
beginning.
For example, for Annex E, GNAT uses the XDR format defined by Sun.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: adasockets and adatypes

[Ted Dennison]

In article <mailman.999618666.14306.comp.lang.ada@ada.eu.org>, David C. Hoos
says...
>From: "Ted Dennison" <dennison@telepath.com>
>One can't.  That's why when stream format is important, one should define
>his own types -- although I've never found a reason not to use the language-

For a single-developer app that might be a good way to handle it. But in many
situations this is just not a feasible solution. For a non-trivial systems its a
*lot* of work to redefine every IO attribute for every type. Some *can't* easily
be redefined (I think 'Class'Output is like this). Let's also not forget that
we've now distributed responsibility for the I/O working properly out to every
single author and maintainer of every single type in the system. 

>> If you only have 2 implementations to get talking, it is fairly easy to
>> massage one end until it talks like the other. That isn't the same thing as 
>> true portability.
>I agree. one should define what the stream should look like from the
>beginning.
>For example, for Annex E, GNAT uses the XDR format defined by Sun.

Ahhh. That's a very good example, in that they shared a small part of this
problem. They still don't have to worry about differing vendor implementations,
but they at least had to worry about different platforms. They solved this
smaller problem by creating a special package that contains all the routines
that will be used by the base type's IO attributes to construct their stream
representations. Users can then override this package with one of their own
devising (including the XDR-based one that comes with GLADE).

Its cool that they did this, but this kind of hook into the inner workings of
the compiler is most definitely *not* part of the Ada standard. It should go
without saying that it won't come close to working with any other compiler.
Perhaps that issue should be addressed for a future language revision. However,
for now there is clearly no good way to accomplish general stream data
portability within Ada. Your only alternatives today are to subset the problem
into one of:

o  - portability when only using Gnat with the XDR version of
System.Stream_Attributes installed
o  - portability when only using a certian subset of types
o  - portability between n specific compilers/platforms (n > 2 only for
masochists)

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

Re: adasockets and adatypes

[David C. Hoos]

First of all, one doesn't redefine 'Output or 'Input -- just
'Read and 'Write.

For example, when you have a spec that defines the network
format,  the only practical way to insure that the representation
of the components is what is specified is to "bite the bullet"
and do the work.

One only needs to do this for simple types and for some
cases of simple records where the components either do not
fully occupy their bytes.

Since you have an incorrect opinion about 'Class'Output, perhaps
it would be better to give an example of something that can't
easily be redefined, and demonstrate with working code how _you_
would do it.

All non-trivial systems require a *lot* of work on many fronts, so
this is nothing new.

There are only two IO attributes to be defined for every type,
and many of them can be done with instantiations of generic
procedures.

One of the most frequent things that has to be re-done when
porting Ada code to new platforms and/or new compilers is
to define types of the correct size and representation, where the
original developers used language-defined types which just
happened to be of the correct size for the original platform and
compiler. I know whereof I speak, because I personally have
ported over a million lines of code with problems like this.

One case I remember was when the VADS compiler changed the
definition of the type Float from one version of the compiler to
the next.  In one case Float was defined as equivalent to Long_Float,
in one version, and as equivalent to Short_Float in the other.

----- Original Message -----
From: "Ted Dennison" <dennison@telepath.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, September 04, 2001 1:53 PM
Subject: Re: adasockets and adatypes


> In article <mailman.999618666.14306.comp.lang.ada@ada.eu.org>, David C.
Hoos
> says...
> >From: "Ted Dennison" <dennison@telepath.com>
> >One can't.  That's why when stream format is important, one should define
> >his own types -- although I've never found a reason not to use the
language-
>
> For a single-developer app that might be a good way to handle it. But in
many
> situations this is just not a feasible solution. For a non-trivial systems
its a
> *lot* of work to redefine every IO attribute for every type. Some *can't*
easily
> be redefined (I think 'Class'Output is like this). Let's also not forget
that
> we've now distributed responsibility for the I/O working properly out to
every
> single author and maintainer of every single type in the system.
>
> >> If you only have 2 implementations to get talking, it is fairly easy to
> >> massage one end until it talks like the other. That isn't the same
thing as
> >> true portability.
> >I agree. one should define what the stream should look like from the
> >beginning.
> >For example, for Annex E, GNAT uses the XDR format defined by Sun.
>
> Ahhh. That's a very good example, in that they shared a small part of this
> problem. They still don't have to worry about differing vendor
implementations,
> but they at least had to worry about different platforms. They solved this
> smaller problem by creating a special package that contains all the
routines
> that will be used by the base type's IO attributes to construct their
stream
> representations. Users can then override this package with one of their
own
> devising (including the XDR-based one that comes with GLADE).
>
> Its cool that they did this, but this kind of hook into the inner workings
of
> the compiler is most definitely *not* part of the Ada standard. It should
go
> without saying that it won't come close to working with any other
compiler.
> Perhaps that issue should be addressed for a future language revision.
However,
> for now there is clearly no good way to accomplish general stream data
> portability within Ada. Your only alternatives today are to subset the
problem
> into one of:
>
> o  - portability when only using Gnat with the XDR version of
> System.Stream_Attributes installed
> o  - portability when only using a certian subset of types
> o  - portability between n specific compilers/platforms (n > 2 only for
> masochists)
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: adasockets and adatypes

[Ted Dennison]

In article <mailman.999636185.20412.comp.lang.ada@ada.eu.org>, David C. Hoos
says...
>
>First of all, one doesn't redefine 'Output or 'Input -- just
>'Read and 'Write.

If you don't specify those attributes, then how do you specify how many bytes
are used to specify the length of a string written out using 'Output (and the
endian-ness of that value). A portable solution will need to do that.

I can actually agree with most of the rest of the message. The problem is that
it still doesn't change the fact that you *can't* do this portably in the
general case. Sure, you can restrict your portability to certain types,
compilers, or platform combos, and get it to work with a bit of elbow grease.
But in the *general* case, you can't do it.

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

Re: adasockets and adatypes

[Marin David Condic]

Also, just because you can get there by rolling-your-own operations, in my
mind isn't the same as saying 'Input and 'Output produce "portable" results.
If I've got to go to the extreme of first thoroughly defining the
representation of all the data types involved and second defining 'Input and
'Output for everything involved, then I might just as well have done a
little bit-twiddling with Unchecked_Conversion, etc., and produced my own
message catalog. You already have the rep clauses you need (maybe even fewer
of them!) and one Unchecked_Conversion or overlay later and you're there.

And I still think you've got issues that don't let you absolutely guarantee
representation - at least not if the requirement is that you must be able to
interface to any arbitrary reader/writer at the other end of the stream. You
certainly have little to no control over the language defined types and,
IIRC, there were issues if you needed to span boundaries or otherwise deal
with a stream that might be produced anywhere by anything.

If you have a sufficiently bounded problem, you can probably get there -
albeit with more effort than I'd like to expend. For some specific set of
messages and some specific set of machines/compilers, you can come up with a
consistent production/consumption of the data. But I think you have a hard
time dealing with the more general cases.

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/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:1v6l7.3307$4z.6132@www.newsranger.com...
> In article <mailman.999615244.13142.comp.lang.ada@ada.eu.org>, David C.
Hoos
> says...
> >This is simply not so. If the record component types have user-defined
> >endianness-independent stream attributes, then the data will have the
>
> How does one do this for language-defined types? Every Ada compiler I've
tried
> it on (including gnat 3.13p just now) only allows one to redefine the IO
> attributes in the same declaration section in which the type is declared.
>
> If you only have 2 implementations to get talking, it is fairly easy to
massage
> one end until it talks like the other. That isn't the same thing as true
> portability.
>

Re: adasockets and adatypes

[Tony Gair]

Thanks David,
        This worked for me, as it happened I did not need the Sigada example

On Tue, 4 Sep 2001 06:37:00 -0500
"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:

> Yes.
> 
> Make the record a tagged type, and use 'Output to send it
> and 'Input to read it.
> 
> The External_Tag of the tagged type will be sent first,
> so that the receiver can determine its type.
> 
> You will need to use the Stream operations of adasocketa.
> 
> ----- Original Message -----
> From: "Tony Gair" <tonygair@blueyonder.co.uk>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: September 04, 2001 5:53 AM
> Subject: adasockets and adatypes
> 
> 
> 
> Does anyone know a way of sending an adatype (especially a record of string
> and enumerated types) down a socket so it can be received by another ada
> program which recognises the type....
> 
> Regards
> Tony Gair
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: adasockets and adatypes

[Marc A. Criley]

Tony Gair wrote:
> 
> Does anyone know a way of sending an adatype (especially a record of string and enumerated types) down a socket so it can be received by another ada program which recognises the type....
> 
> Regards
> Tony Gair

Certainly!  <plug>See my article in Ada Letters:
http://www.acm.org/sigs/sigada/ada_letters/issues/june2001/socket_streams.pdf
</plug>

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: adasockets and adatypes

[Marin David Condic]

Look into Ada.Streams and the 'Input and 'Output attributes. That will get a
record type into a stream which you can then send down a socket. I believe
Marc Criley wrote an article on this for a recent issue of Ada Letters, so
if you have it or can get it, you may find a good description there of what
you want to do. It works fine, except for......

You can't guarantee portability using these operations. If you have the same
machine type, OS type, OS version, Compiler brand, Compiler version at both
ends of the stream, you can be pretty sure that what you put into the stream
will be picked apart properly at the other end. Violate one or more of those
constraints and its all up for grabs.

Note that this is a *theoretical* situation only. You might find that all
versions of your compiler represent the data the same way on all platforms.
You might even accidentally discover that multiple brands of compiler do the
same thing. If you test the representation across your intended platforms
and it works - great. Otherwise, you've got to build your own mechanisms to
control the representation and get it into/out of the stream you are sending
up and down the socket.

Note that while I may complain about this from time to time, you're still
better off than you are with C in the same situation. In C you have very
little control over representation and in general just have to rely on the
fact that most C compilers choose to do things basically the same way. The
one advantage C has in this area is that it is at least simpler to take just
about any data structure and treat it as raw bytes. You can get there in
Ada, but it does require more work.

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/


"Tony Gair" <tonygair@blueyonder.co.uk> wrote in message
news:20010904115244.24236db3.tonygair@blueyonder.co.uk...
>
> Does anyone know a way of sending an adatype (especially a record of
string and enumerated types) down a socket so it can be received by another
ada program which recognises the type....
>
> Regards
> Tony Gair

Re: adasockets and adatypes

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Note that while I may complain about this from time to time, you're
> still better off than you are with C in the same situation. In C you
> have very little control over representation and in general just
> have to rely on the fact that most C compilers choose to do things
> basically the same way. The one advantage C has in this area is that
> it is at least simpler to take just about any data structure and
> treat it as raw bytes. You can get there in Ada, but it does require
> more work.

I would have thought the ideal non-automated C way of doing this would
be to define a wire format that is convenient for manipulating
endianness (eg, no packing) and manually stuff this on the way
out/unstuff on the way in. Far less dangerous than trying to
manipulate packed data.

Sometimes the transport mechanism forces you to use the same length
for every component -- eg, X properties, where you can choose 1/2/4
byte length and the server byteswaps for you.

Re: adasockets and adatypes

[Ole-Hjalmar Kristensen]

Simon Wright <simon@pushface.org> writes:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> 
> > Note that while I may complain about this from time to time, you're
> > still better off than you are with C in the same situation. In C you
> > have very little control over representation and in general just
> > have to rely on the fact that most C compilers choose to do things
> > basically the same way. The one advantage C has in this area is that
> > it is at least simpler to take just about any data structure and
> > treat it as raw bytes. You can get there in Ada, but it does require
> > more work.
> 
> I would have thought the ideal non-automated C way of doing this would
> be to define a wire format that is convenient for manipulating
> endianness (eg, no packing) and manually stuff this on the way
> out/unstuff on the way in. Far less dangerous than trying to
> manipulate packed data.
> 
> Sometimes the transport mechanism forces you to use the same length
> for every component -- eg, X properties, where you can choose 1/2/4
> byte length and the server byteswaps for you.

And don't forget that there are automated tools for doing this in C,
the most widespread is probably SUN's XDR/rpcgen, which always has
been freely available.  From an XDR interface specification, rpcgen
will happily generate both server and client side subs, and indeed a
skeleton server, if you wish. As the XDR format is a wire format,
there are no problems with different compilers and endianness.  rpcgen
essentially eliminated the extra manual work in writing bread and
butter client/server applications years ago.

Of course, there is nothing stopping you from calling the generated C
stubs from Ada.

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: adasockets and adatypes

[Peter Dulimov]

Getting a bit off the original topic here, but ...

Is there a freely available XDR to Ada translator?  I have heard of the Ada
Corba effort, but being an old-fashioned kind of person I would prefer an
OSF-DCE implementation for Ada (the part dealing with RPC that is).  I guess
linking into object files produced by compiling automatically generated C
code is acceptable, but it raises the barrier to "broad general acceptance"
just a little bit further.

Also, what about the efficiency consideration?  The compiler generally
chooses the best representation that it can to get alignment right for
complicated data types, and if you go specifying every bit's position, you
are likely to introduce more fix-up delays.  When I have done this
(specifying bit patterns for socket comms with C programs etc), I have had a
type defined for "on the wire" where the representation is specified, and
another equivalent type for internal usage where I let the compiler choose
the representation.  The conversion from one type to another is the last
thing that happens {before hitting  | after leaving} the wire.

Regards,

Peter Dulimov.

Ole-Hjalmar Kristensen wrote:

[snip]

> And don't forget that there are automated tools for doing this in C,
> the most widespread is probably SUN's XDR/rpcgen, which always has
> been freely available.  From an XDR interface specification, rpcgen
> will happily generate both server and client side subs, and indeed a
> skeleton server, if you wish. As the XDR format is a wire format,
> there are no problems with different compilers and endianness.  rpcgen
> essentially eliminated the extra manual work in writing bread and
> butter client/server applications years ago.
>
> Of course, there is nothing stopping you from calling the generated C
> stubs from Ada.
>
> --
> Kabelsalat ist gesund.
>
> Ole-Hj. Kristensen

Re: adasockets and adatypes

[Ted Dennison]

In article <3B98C898.99D7A1F6@eraseme.systems.saab.se>, Peter Dulimov says...
>Is there a freely available XDR to Ada translator?  I have heard of the Ada

GLADE uses XDR encodings, so it contains code to transform Ada structures to XDR
and back. I suspect that code only knows how to Ada-ize XDR data that *it*
created, but I don't know how flexible XDR is; perhaps that is enough.

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

Re: adasockets and adatypes

[Simon Wright]

Peter Dulimov <pedu@eraseme.systems.saab.se> writes:

> Also, what about the efficiency consideration?  The compiler
> generally chooses the best representation that it can to get
> alignment right for complicated data types, and if you go specifying
> every bit's position, you are likely to introduce more fix-up
> delays.  When I have done this (specifying bit patterns for socket
> comms with C programs etc), I have had a type defined for "on the
> wire" where the representation is specified, and another equivalent
> type for internal usage where I let the compiler choose the
> representation.  The conversion from one type to another is the last
> thing that happens {before hitting | after leaving} the wire.

Yes.

One Ada possibility here is to specify a type without representation
clauses and then create a wire format subtype with representation
clauses (in a local declarative part). You can make the choice of big-
or little-endian depending on the value of System.Default_Bit_Order[1],
which with any luck will be optimised at compile time so only one
branch is compiled.

[1] Purists would argue that this isn't the same as byte order, though
it always has been for me.

Re: adasockets and adatypes

[Marin David Condic]

Not exactly sure I understand what you are describing, but I will say this:
I've used C to read/write data to a stream and usually, I've resorted to
having some function that manually tore the data apart and put it into the
stream - not dissimilar to creating a 'Read or 'Write procedure for some
structure. I've had to do that because C didn't provide a good way for me to
control where the bits and bytes fell within a struct and the minute
something got the least bit unusual, you just couldn't get there with its
lame representation specifications. In simpler cases where I got to define
the message content, you could basically build a struct that was at least
consistent and do some kind of overlay or similar pointer tricks to just get
it as a stream of bytes.

As for endianness and/or some kind of general portability, I've not had to
deal with that in C because the environment was usually self-contained
enough that you could be sure that both ends were doing the same thing.
Those who insist on absolute portability don't have the balls to live in the
real world. :-)

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/


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vpu96ehbx.fsf@smaug.pushface.org...
>
> I would have thought the ideal non-automated C way of doing this would
> be to define a wire format that is convenient for manipulating
> endianness (eg, no packing) and manually stuff this on the way
> out/unstuff on the way in. Far less dangerous than trying to
> manipulate packed data.
>
> Sometimes the transport mechanism forces you to use the same length
> for every component -- eg, X properties, where you can choose 1/2/4
> byte length and the server byteswaps for you.