Can this data be represented in Ada?

Can this data be represented in Ada?

[Scot Mcintosh]

I'm implementing a data communications protocol that has some data
structural features that don't look possible to implement in Ada.
Perhaps someone more experienced can suggest a way to accomplish
what I'm trying to do (changing the protocol is not an option).

A Transmission Unit looks like:

+---------+----------+-----------+------+
| Packet  |  Packet1 |  Packet2  | etc  |
| Length  |          |           |  ... |
+---------+----------+-----------+------+
    |     |<-------->|<--------->|
    |          ^          ^
    |          |          |
    |__________|__________+


Each Packet looks like:

+---------+----------+--------------+
| Data    |  Data    |  Padding     | 
| Length  |          |(i.e. nothing)| 
+---------+----------+--------------+
|   |     |<-------->               |
|   |          ^                    |
|   |          |                    |
|   |__________|                    |
|                                   |
|<--------------------------------->|
        Packet Length

For a given transmission, the Packet Length is fixed, but can be
different in the next transmission. The Data Length within each
Packet can be different for each Packet. I've tried to figure out how
to define Ada types for the Transmission Unit and Packet that
allow for the variability of the field sizes and haven't succeeded.
Any ideas? Thanks in advance.


-- 
----
Scot McIntosh
Internet: psm%helios.nosc.mil@nosc.mil
UUCP:     I have no idea

Re: Can this data be represented in Ada?

[agate!linus!linus.mitre.org!linus!sdl]

In article <1992Dec31.014719.22174@nosc.mil> psm@nosc.mil (Scot Mcintosh) write
s:

> I'm implementing a data communications protocol that has some data
> structural features that don't look possible to implement in Ada.
> Perhaps someone more experienced can suggest a way to accomplish
> what I'm trying to do (changing the protocol is not an option).
> 
> A Transmission Unit looks like:
> 
> +---------+----------+-----------+------+
> | Packet  |  Packet1 |  Packet2  | etc  |
> | Length  |          |           |  ... |
> +---------+----------+-----------+------+
>     |     |<-------->|<--------->|
>     |          ^          ^
>     |          |          |
>     |__________|__________+
> 
> 
> Each Packet looks like:
> 
> +---------+----------+--------------+
> | Data    |  Data    |  Padding     | 
> | Length  |          |(i.e. nothing)| 
> +---------+----------+--------------+
> |   |     |<-------->               |
> |   |          ^                    |
> |   |          |                    |
> |   |__________|                    |
> |                                   |
> |<--------------------------------->|
> 	Packet Length
> 
> For a given transmission, the Packet Length is fixed, but can be
> different in the next transmission. The Data Length within each
> Packet can be different for each Packet. 

You didn't happen to state how you know when you have read in all the
packets for a given Transmission Unit--is there some
"end-of-transmission" indicator?

You didn't happen to state how "data length" is related to "data".
I'll assume that "data" is in the form of a stream of bytes; and
that "data length" and "packet length" are two-byte integers giving
the number of bytes in Data and Packet, respectively.

   type BYTE is range 0 .. 255;
   for BYTE'SIZE use 8;
   subtype DATA_BYTE is BYTE;

   type LENGTH is range 0 .. 50000;      -- or whatever
   for LENGTH'SIZE use 16;

   DATA_LENGTH, PACKET_LENGTH:  LENGTH;
    
I suggest it's easier to simply define everything as an
undifferentiated stream of bytes, and use UNCHECKED_CONVERSION to
extract the more complicated, higher-level structure after you read in
the needed bytes.

The major use of UNCHECKED_CONVERSION, I have found, is to read in
low-level data representations (like bit streams or byte streams), and
then convert them to whatever high-level representation you wish after
you have interrogated them to find out their dynamic structure.

So you can read the first two bytes, and then use UNCHECKED_CONVERSION
to convert it to the integer type LENGTH.  Then that's the Packet
Length; you know you must read in that number of bytes for each
subsequent packet.  So for each subsequent packet, read in a number of
bytes given by Packet Length; use UNCHECKED_CONVERSION to convert the
first two bytes to an integer (which represents Data Length); then
process that number of subsequent bytes as Data, ignoring the rest.



--
Steven Litvintchouk
MITRE Corporation
202 Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753
ARPA:  sdl@mitre.org
UUCP:  linus!sdl
	"Where does he get those wonderful toys?"

Re: Can this data be represented in Ada?

[James Crigler]

psm@nosc.mil (Scot Mcintosh) writes:

>I'm implementing a data communications protocol that has some data
>structural features that don't look possible to implement in Ada.
>Perhaps someone more experienced can suggest a way to accomplish
>what I'm trying to do (changing the protocol is not an option).

>A Transmission Unit looks like:

[Picture deleted]


>Each Packet looks like:

[Picture deleted]

>For a given transmission, the Packet Length is fixed, but can be
>different in the next transmission. The Data Length within each
>Packet can be different for each Packet. I've tried to figure out how
>to define Ada types for the Transmission Unit and Packet that
>allow for the variability of the field sizes and haven't succeeded.
>Any ideas? Thanks in advance.

I've done this kind of thing before, and it's not easy to map this kind
of structure at compile time:  Ada just won't let you do it.  However,
it may be possible to create your structure at run time by use of blocks
contained in procedures.  Below is a little idea.  I've filled in some
stuff by assumption.

procedure CREATE_TRANSMISSION (PACKET_SIZE : in POSITIVE,
			       [other parms as required]) is

  subtype PACKET_LENGTH is POSITIVE range 1 .. 255; -- or whatever
  subtype DATUM         is NATURAL  range 0 .. 255; -- or whatever
  type PACKET_DATA is array (1 .. PACKET_SIZE - 1) of DATUM;
  type PACKET is record
    DATA_SIZE : POSITIVE;
    DATA      : PACKET_DATA;
  end record;

  TRANSIMISSION_UNIT_SIZE : constant := 1024;

  PACKET_COUNT : constant := TRANSMISSION_UNIT_SIZE / PACKET_SIZE;
  -- But if it can be an even multiple, subtract 1.

  type TRANSMISSION_UNIT is record
    PACKET_SIZE : PACKET_LENGTH;
    PACKET      : array (1 .. PACKET_COUNT) of PACKET;
  end record;

  -- Put necessary procedures to fill in data here, followed by
  -- main body of procedure.


At the receiving end, use a system like this:

with SYSTEM;

package body FRED is

subtype PACKET_LENGTH is POSITIVE range 1 .. 255; -- or whatever
subtype DATUM         is NATURAL  range 0 .. 255; -- or whatever
TRANSIMISSION_UNIT_SIZE : constant := 1024;

type RECEPTION_UNIT is record
  PACKET_SIZE : PACKET_LENGTH;
  DATA        : ARRAY (1 .. TRANMISSION_UNIT_SIZE - 1) of DATUM;
end record;

procedure DECODE_DATA (DATA : in RECEPTION_UNIT) is

  type PACKET_DATA is array (1 .. DATA.PACKET_SIZE - 1) of DATUM;
  type PACKET_REC is record
    DATA_SIZE : PACKET_LENGTH;
    DATA      : PACKET_DATA;
  end record;

  PACKET_COUNT : constant := TRANSMISSION_UNIT_SIZE / DATA.PACKET_SIZE;
  -- But if it can be an even multiple, subtract 1.

  type PACKET_ARRAY is array (1 .. PACKET_COUNT) of PACKET_REC;
  PACKET : PACKET_ARRAY; for PACKET use at DATA.DATA'ADDRESS;
  [other declarations and procedure body]



I haven't used anything like this in a long time but I think it should
work.  The trick here is that the in mode parameter PACKET_SIZE is
a constant at run time from the procedure's point of view.  There are
two problems:

    1.  A hit in run time if there is a lot of range checking to do.
        Remember that the language is required to do a lot of "safety"
	checking behind your back, so you may have to program to
	defend yourself against the language.

    2.  You don't get a global "type" that you can put in a package
	spec for the world to see.

Hope this sheds a little lux et veritas.

Jim Crigler
------------------------------------------------------
!PC

Re: Can this data be represented in Ada?

[Stephe Leake]

In article <1992Dec31.014719.22174@nosc.mil> psm@nosc.mil (Scot Mcintosh) write
s:

> I'm implementing a data communications protocol that has some data
> structural features that don't look possible to implement in Ada.
> Perhaps someone more experienced can suggest a way to accomplish
> what I'm trying to do (changing the protocol is not an option).
> 
> A Transmission Unit looks like:
> 
> +---------+----------+-----------+------+
> | Packet  |  Packet1 |  Packet2  | etc  |
> | Length  |          |           |  ... |
> +---------+----------+-----------+------+
>     |     |<-------->|<--------->|
>     |          ^          ^
>     |          |          |
>     |__________|__________+
> 
> 
> Each Packet looks like:
> 
> +---------+----------+--------------+
> | Data    |  Data    |  Padding     | 
> | Length  |          |(i.e. nothing)| 
> +---------+----------+--------------+
> |   |     |<-------->               |
> |   |          ^                    |
> |   |          |                    |
> |   |__________|                    |
> |                                   |
> |<--------------------------------->|
> 	Packet Length
> 
> For a given transmission, the Packet Length is fixed, but can be
> different in the next transmission. The Data Length within each
> Packet can be different for each Packet. 

In article <SDL.92Dec31182221@rigel.linus.mitre.org>, sdl@linus.mitre.org (Stev
en D. Litvintchouk) writes...
> 
>You didn't happen to state how you know when you have read in all the
>packets for a given Transmission Unit--is there some
>"end-of-transmission" indicator?
> 
>You didn't happen to state how "data length" is related to "data".
>I'll assume that "data" is in the form of a stream of bytes; and
>that "data length" and "packet length" are two-byte integers giving
>the number of bytes in Data and Packet, respectively.
> 
>   type BYTE is range 0 .. 255;
>   for BYTE'SIZE use 8;
>   subtype DATA_BYTE is BYTE;
> 
>   type LENGTH is range 0 .. 50000;      -- or whatever
>   for LENGTH'SIZE use 16;
> 
>   DATA_LENGTH, PACKET_LENGTH:  LENGTH;
>    
>I suggest it's easier to simply define everything as an
>undifferentiated stream of bytes, and use UNCHECKED_CONVERSION to
>extract the more complicated, higher-level structure after you read in
>the needed bytes.
> ... 
>So you can read the first two bytes, and then use UNCHECKED_CONVERSION
>to convert it to the integer type LENGTH.  Then that's the Packet
>Length; you know you must read in that number of bytes for each
>subsequent packet.  So for each subsequent packet, read in a number of
>bytes given by Packet Length; use UNCHECKED_CONVERSION to convert the
>first two bytes to an integer (which represents Data Length); then
>process that number of subsequent bytes as Data, ignoring the rest.
> 

This is a valid way to PROCESS the data, but it is not a way to REPRESENT the
data structure. I tried a couple approaches involving unconstrained arrays, but
since the max length of a packet is specified at run time, it cannot be static.
Thus this structure is not REPRESENTABLE in Ada. As an Ada advocate, my
reaction to this is twofold; first, there is probably a better data structure
that is representable. Second, at least Ada can process the data in a
reasonable way; maybe actually representing the structure is not required.
There are certainly other applications (complex cross-linked lists) where the
actual structure is only partly represented by Ada types.

Re: Can this data be represented in Ada?

[Robert I. Eachus]

In article <4JAN199313495649@robots> nbssal@robots (Stephe Leake) writes:


  > This is a valid way to PROCESS the data, but it is not a way to
  > REPRESENT the data structure. I tried a couple approaches
  > involving unconstrained arrays, but since the max length of a
  > packet is specified at run time, it cannot be static.  Thus this
  > structure is not REPRESENTABLE in Ada. As an Ada advocate, my
  > reaction to this is twofold; first, there is probably a better
  > data structure that is representable. Second, at least Ada can
  > process the data in a reasonable way; maybe actually representing
  > the structure is not required.  There are certainly other
  > applications (complex cross-linked lists) where the actual
  > structure is only partly represented by Ada types.

    I would guess that Steve picked the problem of reading such data
from the transmission media as the interesting part, the data
structure is easily representable in Ada:

  -- Steve's utility types...

   type BYTE is range 0 .. 255;
   for BYTE'SIZE use 8;
   subtype DATA_BYTE is BYTE;
 
   type LENGTH is range 0 .. 50000;      -- or whatever
   for LENGTH'SIZE use 16;
 
procedure Generate_Packets(Packet_Size: in Length; Message: in String) is 

   No_of_Packets: constant Length :=
           (Message'LENGTH + Packet_Size - 3) / (Packet_Size - 2);
   -- Compute number of packets needed.

   type Byte_Array is array(Length range <>) of Byte;
   
   type Contents(DATA_LENGTH: LENGTH := Packet_Size-2) is record
     DATA: Byte_Array(1..DATA_LENGTH);
     FILLER: Byte_Array(DATA_LENGTH..PACKET_SIZE-3);
   end record;

   type Packet is record
     C: Contents;	
   end record;

   type Packet_Array is array(1..No_of_Packets) of Packet;

   type Transmission is record
     L: Length := Packet_Size;
     P: Packet_Array;
   end record;

   package Packet_IO is new Sequential_IO(Transmission);
   
   The_Message: Transmission;

begin

  -- Fill in the message
  -- open the file (pipe?)
  -- send the messaage
  -- close pipe.
  null;
end Generate_Packets;

    There is no particular reason to have the type Contents and have
the data size as a discriminant in Ada. (It makes accessing the Data
require slightly fewer keystrokes, but...)  So I really recommend:

   type Packet is record
     Data_Length: Length := Packet_Size-2;
     Data: Byte_Array(1..Packet_Size-2);
   end record;

   An Ada compiler is more likely to represent this without any added
dope information, although some compilers (DEC?) do not require
pragmas or representation clauses to represent the original type
without dope.

    There are a few "tricks" used in the code above, but although they
are surprising to most Ada programmers, they are intentional features
of the language.  (In particular, arrays of records CONTAINING records
with different discriminant values.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...