From: nsisrv!robots!nbssal@ames.arc.nasa.gov (Stephe Leake)
Subject: Re: Can this data be represented in Ada?
Date: 4 Jan 93 18:49:00 GMT [thread overview]
Message-ID: <4JAN199313495649@robots> (raw)
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.
next reply other threads:[~1993-01-04 18:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1993-01-04 18:49 Stephe Leake [this message]
-- strict thread matches above, loose matches on Subject: below --
1993-01-06 19:11 Can this data be represented in Ada? Robert I. Eachus
1993-01-03 5:06 James Crigler
1992-12-31 23:22 agate!linus!linus.mitre.org!linus!sdl
1992-12-31 1:47 Scot Mcintosh
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox