Message passing code

Message passing code

[David Kristola]

Over the years i have worked on a number of projects that have
implemented various message passing schemes for "unique" hardware.
They usually had a number of traits in common (ports and channels).

Is there a standard interface for such things, and if so, is there
source code that will work without modification (i.e. standard Ada)
in a single program, and only need modification in localized
places (child packages) to work with specific hardware?

Thanks for any help that will keep me from reinventing another wheel.

--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Message passing code

[Dale Stanbrough]

dkristol@see-my.sig wrote:

" Over the years i have worked on a number of projects that have
  implemented various message passing schemes for "unique" hardware.
  They usually had a number of traits in common (ports and channels).
  
  Is there a standard interface for such things, and if so, is there
  source code that will work without modification (i.e. standard Ada)
  in a single program, and only need modification in localized
  places (child packages) to work with specific hardware?"


Glade (the ACT implementation of the Ada distributed systems annex)

and 

MPI (message passing interface). I don't know of any Ada bindings, but
i would guess it is pretty trivial from what i have seen.


(I wonder if the two could be combined...)

Dale

Re: Message passing code

[David Kristola]

In article 2406991635080001@dale.cs.rmit.edu.au, dale@cs.rmit.edu.au (Dale Stanbrough) writes:
>dkristol@see-my.sig wrote:
>
>" Over the years i have worked on a number of projects that have
>  implemented various message passing schemes for "unique" hardware.
>  They usually had a number of traits in common (ports and channels).
>  
>  Is there a standard interface for such things, and if so, is there
>  source code that will work without modification (i.e. standard Ada)
>  in a single program, and only need modification in localized
>  places (child packages) to work with specific hardware?"
>
>
>Glade (the ACT implementation of the Ada distributed systems annex)

This does not fit the bill.  I am trying to pass messages, not do
remote procedure calls, and besides, the compiler has no clue how
the hardware is connected.  I get the pleasure of writing that.
By the time i expand on the basic streams concept, well, i am back
to where i started: doing it all myself.  Once i have a basic
message passing system set up, it would be easy to make a stream
interface for it.  But what should that interface look like?

package Ada.Streams.Messages is
   type Stream_Access is access all Root_Stream_Type'Class;
   type Channel_Type is ...
   type Port_Type is limited private;
   procedure Open
      (Port    : in out Port_Type;
       Channel : in     Channel_Type);
   function Stream(Port : in     Port_Type) return Stream_Access;
   -- etc.
end Ada.Streams.Messages;

I can see this causing problems, especially when someone creates their
Write routines to break up large objects into lots of small, discrete
objects.  The data would probably need to be wrapped at a lower level,
and sent over as packets.  This would cause some large objects to be
sent as many small packets, and this could be terrible, depending on
the hardware moving the data.

>MPI (message passing interface). I don't know of any Ada bindings, but
>i would guess it is pretty trivial from what i have seen.

This is pretty close to what i am looking for, but i haven't found
an Ada implementation (a binding would not work because they don't
make what i would need to bind to for the hardware in question).


--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Message passing code

[tmoran]

>I can see this causing problems, especially when someone creates their
>Write routines to break up large objects into lots of small, discrete
>objects.  The data would probably need to be wrapped at a lower level,
>and sent over as packets.  This would cause some large objects to be
>sent as many small packets, and this could be terrible, depending on
  I'm not clear on what you want, but if small packets from the many
small 'Writes worry you, buffer them up.  For writing one or more records
as a single object to the clipboard, or writing it as a single
datagram write, I use a data marshalling package which includes:
  -- Writes to a buffer will allocate additional memory from the
  -- heap as needed.  If you know reasonably accurately how much
  -- you'll need, it will be more efficient to make the
  -- Initial_Length big enough and thus avoid heap allocation.
  --
  -- Any heap allocation will be freed automatically when a Buffer
  -- ceases to exist.

  type Buffer_Type(Initial_Length : Ada.Streams.Stream_Element_Count)
  is new Ada.Streams.Root_Stream_Type with private;

  procedure Write(Stream : in out Buffer_Type;
                  Item   : in     Ada.Streams.Stream_Element_Array);
etc.
Does that address (part of) the problem?

Re: Message passing code

[David Kristola]

In article 123270@typhoon-sf.snfc21.pbi.net, tmoran@bix.com () writes:
>>I can see this causing problems, especially when someone creates their
>>Write routines to break up large objects into lots of small, discrete
>>objects.  The data would probably need to be wrapped at a lower level,
>>and sent over as packets.  This would cause some large objects to be
>>sent as many small packets, and this could be terrible, depending on
>  I'm not clear on what you want, but if small packets from the many
>small 'Writes worry you, buffer them up.  For writing one or more records
>as a single object to the clipboard, or writing it as a single
>datagram write, I use a data marshalling package which includes:
>  -- Writes to a buffer will allocate additional memory from the
>  -- heap as needed.  If you know reasonably accurately how much
>  -- you'll need, it will be more efficient to make the
>  -- Initial_Length big enough and thus avoid heap allocation.
>  --
>  -- Any heap allocation will be freed automatically when a Buffer
>  -- ceases to exist.
>
>  type Buffer_Type(Initial_Length : Ada.Streams.Stream_Element_Count)
>  is new Ada.Streams.Root_Stream_Type with private;
>
>  procedure Write(Stream : in out Buffer_Type;
>                  Item   : in     Ada.Streams.Stream_Element_Array);
>etc.
>Does that address (part of) the problem?

Not really.  How does the lower level know when the writing to
the stream is done, and it should send the buffer?  I guess there
could be an explicit Flush command.  But now i am doing all kinds
of things that don't look like streams any more, so what is the
point of trying to look like streams?

I don't think streams are the right paradigm for this. When i have
a message to send, i want to send the whole thing.  That message
will have many different things inside of it, and may be different
lengths.  I would also have to code a Write routine for each
message type.  That could get ugly.  I would rather stick to the
old technique of converting it to an array of bytes, and passing
those into a Send routine.

   -- Completely bogus type for example.
   type Message_Type is
      record
         Message_ID : Base_Types.Unsigned_Integer_16_Type := Update_Contact_Table;
         Concat_ID  : Contact_Types.Concat_ID_Type;
         Location   : General_Types.Ownship_Relative_Position_Type;
         Condition  : Something_Else.Some_Interesting_Type;
         Detection  : Sonar.Detection_Method_Type;
         Checksum   : Base_Types.Unsigned_Integer_16_Type;
      end record;

   Sonar_Update_Message : Message_Type;

   Sonar_Update_Message.Checksum :=
      Message_Services.Calculate_Checksum(Convert(Sonar_Update_Message));
   MPI.Send(Tactical_Channel, Convert(Sonar_Update_Message));

--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Message passing code

[ada_daddy]

In article <7ksh2u$e1e2@svlss.lmms.lmco.com>,
  dkristol@see-my.sig wrote:
> Over the years i have worked on a number of
projects that have
> implemented various message passing schemes
for "unique" hardware.
> They usually had a number of traits in common
(ports and channels).
>
> Is there a standard interface for such things,
and if so, is there
> source code that will work without modification
(i.e. standard Ada)
> in a single program, and only need modification
in localized
> places (child packages) to work with specific
hardware?
>
> Thanks for any help that will keep me from
reinventing another wheel.

It really depends upon what you mean by message
passing systems.
If you want to pass messages between Ada tasks,
then yes.
Ada provides Rendezvous and protected objects for
passing
messages between tasks. These are all implemented
in a
hardware independent manner.

Jim Rogers
Omnitech Robotics, Inc.
Englewood, Colorado


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Message passing code

[Bruce or Tracy]

At work, we are currently using Ada.Stream.  This is
the mechanism for (at least parts of) HLA (High
Level Architecture) where separate simulations 
communicate via a Run Time Infrastructure package.

In the past, others used IEEE standards' formatted
text strings in the DIS world.  

In these instances, the format of the message as
well as the mechanism were a standard for that
particular certification.

ada_daddy@my-deja.com wrote:
> 
> In article <7ksh2u$e1e2@svlss.lmms.lmco.com>,
>   dkristol@see-my.sig wrote:
> > Over the years i have worked on a number of
> projects that have
> > implemented various message passing schemes
> for "unique" hardware.
> > They usually had a number of traits in common
> (ports and channels).
> >
> > Is there a standard interface for such things,
> and if so, is there
> > source code that will work without modification
> (i.e. standard Ada)
> > in a single program, and only need modification
> in localized
> > places (child packages) to work with specific
> hardware?
> >
> > Thanks for any help that will keep me from
> reinventing another wheel.
> 
> It really depends upon what you mean by message
> passing systems.
> If you want to pass messages between Ada tasks,
> then yes.
> Ada provides Rendezvous and protected objects for
> passing
> messages between tasks. These are all implemented
> in a
> hardware independent manner.
> 
> Jim Rogers
> Omnitech Robotics, Inc.
> Englewood, Colorado
> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Re: Message passing code

[Jim Rogers]

In article <3772AD75.F5E8AAED@hiwaay.net>,
  Bruce or Tracy <bljacobs@hiwaay.net> wrote:
> At work, we are currently using Ada.Stream.  This is
> the mechanism for (at least parts of) HLA (High
> Level Architecture) where separate simulations
> communicate via a Run Time Infrastructure package.
>
> In the past, others used IEEE standards' formatted
> text strings in the DIS world.
>
> In these instances, the format of the message as
> well as the mechanism were a standard for that
> particular certification.
>

Ada.Streams is a very good tool. It is not, however, a standard
beyond the world of Ada. Ada.Streams is a tool for converting
between a binary data stream and internal Ada object representation.
The binary data stream format must still be "standardized", or
at least agreed upon by all applications cooperating in a
communication community.

--
Jim Rogers
Colorado Springs, Colorado USA


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Message passing code

[Ted Dennison]

In article <7l0gj5$b62$1@nnrp1.deja.com>,
  Jim Rogers <ada_daddy@my-deja.com> wrote:
> In article <3772AD75.F5E8AAED@hiwaay.net>,
>   Bruce or Tracy <bljacobs@hiwaay.net> wrote:
> > At work, we are currently using Ada.Stream.  This is
> > the mechanism for (at least parts of) HLA (High
> > Level Architecture) where separate simulations
> > communicate via a Run Time Infrastructure package.
>
> Ada.Streams is a very good tool. It is not, however, a standard
> beyond the world of Ada. Ada.Streams is a tool for converting
> between a binary data stream and internal Ada object representation.
> The binary data stream format must still be "standardized", or
> at least agreed upon by all applications cooperating in a
> communication community.

That's true. In fact, I don't think it is even guaranteed to work
between different platforms or compilers. You don't know what
Ada.Streams.Stream_Element is, or how big it is. Unless you write it
yourself, you don't know how your stream is implemented or how data gets
placed in it. Encryption or compression could be going on, for all you
know. Unless you write them yourself, you don't know how 'Read and
'Write are converting between your objects and stream elements.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Message passing code

[Robert Dewar]

In article <7l0s5k$g32$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> Unless you write them yourself, you don't know how 'Read and
> 'Write are converting between your objects and stream
> elements.

I certainly HOPE this is false with any reasonable Ada 95
compiler. It should be quite transparent what the conversion
mechanism is. In the case of GNAT, you can look at s-stratt.adb
which encapsulates the conversions used (we have two versions
that are standard, and easy to read and understand, one for
native format, and one which uses XDR for platform
independence). You can if you like write your own version of
s-stratt.adb to control the underlying default translations
that are used.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Message passing code

[Jim Rogers]

In article <7l6lni$4a5$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <7l0s5k$g32$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
>
> > Unless you write them yourself, you don't know how 'Read and
> > 'Write are converting between your objects and stream
> > elements.
>
> I certainly HOPE this is false with any reasonable Ada 95
> compiler. It should be quite transparent what the conversion
> mechanism is. In the case of GNAT, you can look at s-stratt.adb
> which encapsulates the conversions used (we have two versions
> that are standard, and easy to read and understand, one for
> native format, and one which uses XDR for platform
> independence). You can if you like write your own version of
> s-stratt.adb to control the underlying default translations
> that are used.

Unfortunately, I have had some nasty surprises in this area from
ObjectAda.

Example:

   type Byte is mod 2**8;
   for Byte'Size use 8;

I assumed that the native stream representation of the above type
would be represented in 8 bits. In fact it is represented on the
stream in 32 bits. The only way I could assure that this type would
occupy only 8 bits in my stream was to write customized 'Read and 'Write
procedures.

Aonix calls this a feature. They use the Intermetrics front end.
Apparently this is the behavior preferred by Tucker Taft, who insists
that the stream should represent all values by the size of the Base
type, and the Base type for all integer types is Universal Integer.

This is my understanding of the Aonix rationale. I am sure I will be
corrected if I am wrong.

--
Jim Rogers
Colorado Springs, Colorado USA


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Message passing code

[Bruce or Tracy]

Right, Ada.Streams is not the standard - the standard was the
IEEE DIS interface.

Ada.Streams, now that we are using Ada95 (finally!), is the
agreed upon communication interface mechanism between us and
our RTI.  How RTI communications with the rest of the world
is decided, as I understand it, between RTI and the rest of
the world.  Ada.Streams is not a stardard by any means.  I 
don't think I said that, but it maybe could have been implied. 

In fact, the RTI itself is in C++.  They have to do a conversion
from our RTI/Ada95 interface mechanism to whatever their C++
requires - I think it uses a base-type of string.

Ada.Streams, as I understand the politics of the situation, is
a hand-shake agreement under the table.  However, our agreement 
was to follow their lead in using Ada.Streams.

The more I use streams, the more I like them.  The 'WRITE and
'READ attributes are very nice - keeps one from having to 
count bytes.  Being Ada95 controlled, insertion and extraction 
errors are *almost* eliminated.

Bruce

Jim Rogers wrote:
> 
> In article <3772AD75.F5E8AAED@hiwaay.net>,
>   Bruce or Tracy <bljacobs@hiwaay.net> wrote:
> > At work, we are currently using Ada.Stream.  This is
> > the mechanism for (at least parts of) HLA (High
> > Level Architecture) where separate simulations
> > communicate via a Run Time Infrastructure package.
> >
> > In the past, others used IEEE standards' formatted
> > text strings in the DIS world.
> >
> > In these instances, the format of the message as
> > well as the mechanism were a standard for that
> > particular certification.
> >
> 
> Ada.Streams is a very good tool. It is not, however, a standard
> beyond the world of Ada. Ada.Streams is a tool for converting
> between a binary data stream and internal Ada object representation.
> The binary data stream format must still be "standardized", or
> at least agreed upon by all applications cooperating in a
> communication community.
> 
> --
> Jim Rogers
> Colorado Springs, Colorado USA
> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.