home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / ada / 3866 < prev    next >
Encoding:
Text File  |  1993-01-04  |  3.6 KB  |  100 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!linus!linus.mitre.org!linus!sdl
  3. From: sdl@linus.mitre.org (Steven D. Litvintchouk)
  4. Subject: Re: Can this data be represented in Ada?
  5. In-Reply-To: psm@nosc.mil's message of Thu, 31 Dec 1992 01:47:19 GMT
  6. Message-ID: <SDL.92Dec31182221@rigel.linus.mitre.org>
  7. Sender: news@linus.mitre.org (NONUSER)
  8. Nntp-Posting-Host: rigel.mitre.org
  9. Organization: The MITRE Corporation, Bedford, MA
  10. References: <1992Dec31.014719.22174@nosc.mil>
  11. Date: Thu, 31 Dec 1992 23:22:21 GMT
  12. Lines: 86
  13.  
  14.  
  15. In article <1992Dec31.014719.22174@nosc.mil> psm@nosc.mil (Scot Mcintosh) writes:
  16.  
  17. > I'm implementing a data communications protocol that has some data
  18. > structural features that don't look possible to implement in Ada.
  19. > Perhaps someone more experienced can suggest a way to accomplish
  20. > what I'm trying to do (changing the protocol is not an option).
  21. > 
  22. > A Transmission Unit looks like:
  23. > 
  24. > +---------+----------+-----------+------+
  25. > | Packet  |  Packet1 |  Packet2  | etc  |
  26. > | Length  |          |           |  ... |
  27. > +---------+----------+-----------+------+
  28. >     |     |<-------->|<--------->|
  29. >     |          ^          ^
  30. >     |          |          |
  31. >     |__________|__________+
  32. > 
  33. > 
  34. > Each Packet looks like:
  35. > 
  36. > +---------+----------+--------------+
  37. > | Data    |  Data    |  Padding     | 
  38. > | Length  |          |(i.e. nothing)| 
  39. > +---------+----------+--------------+
  40. > |   |     |<-------->               |
  41. > |   |          ^                    |
  42. > |   |          |                    |
  43. > |   |__________|                    |
  44. > |                                   |
  45. > |<--------------------------------->|
  46. >     Packet Length
  47. > 
  48. > For a given transmission, the Packet Length is fixed, but can be
  49. > different in the next transmission. The Data Length within each
  50. > Packet can be different for each Packet. 
  51.  
  52. You didn't happen to state how you know when you have read in all the
  53. packets for a given Transmission Unit--is there some
  54. "end-of-transmission" indicator?
  55.  
  56. You didn't happen to state how "data length" is related to "data".
  57. I'll assume that "data" is in the form of a stream of bytes; and
  58. that "data length" and "packet length" are two-byte integers giving
  59. the number of bytes in Data and Packet, respectively.
  60.  
  61.    type BYTE is range 0 .. 255;
  62.    for BYTE'SIZE use 8;
  63.    subtype DATA_BYTE is BYTE;
  64.  
  65.    type LENGTH is range 0 .. 50000;      -- or whatever
  66.    for LENGTH'SIZE use 16;
  67.  
  68.    DATA_LENGTH, PACKET_LENGTH:  LENGTH;
  69.     
  70. I suggest it's easier to simply define everything as an
  71. undifferentiated stream of bytes, and use UNCHECKED_CONVERSION to
  72. extract the more complicated, higher-level structure after you read in
  73. the needed bytes.
  74.  
  75. The major use of UNCHECKED_CONVERSION, I have found, is to read in
  76. low-level data representations (like bit streams or byte streams), and
  77. then convert them to whatever high-level representation you wish after
  78. you have interrogated them to find out their dynamic structure.
  79.  
  80. So you can read the first two bytes, and then use UNCHECKED_CONVERSION
  81. to convert it to the integer type LENGTH.  Then that's the Packet
  82. Length; you know you must read in that number of bytes for each
  83. subsequent packet.  So for each subsequent packet, read in a number of
  84. bytes given by Packet Length; use UNCHECKED_CONVERSION to convert the
  85. first two bytes to an integer (which represents Data Length); then
  86. process that number of subsequent bytes as Data, ignoring the rest.
  87.  
  88.  
  89.  
  90. --
  91. Steven Litvintchouk
  92. MITRE Corporation
  93. 202 Burlington Road
  94. Bedford, MA  01730
  95.  
  96. Fone:  (617)271-7753
  97. ARPA:  sdl@mitre.org
  98. UUCP:  linus!sdl
  99.     "Where does he get those wonderful toys?"
  100.