home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / ada / 3869 < prev    next >
Encoding:
Text File  |  1993-01-04  |  3.9 KB  |  95 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!nsisrv!robots!nbssal
  3. From: nbssal@robots (Stephe Leake)
  4. Subject: Re: Can this data be represented in Ada?
  5. Message-ID: <4JAN199313495649@robots>
  6. News-Software: VAX/VMS VNEWS 1.4-b1  
  7. Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet)
  8. Nntp-Posting-Host: robots.gsfc.nasa.gov
  9. Organization: NASA Goddard Robotics Lab
  10. References: <1992Dec31.014719.22174@nosc.mil> <SDL.92Dec31182221@rigel.linus.mitre.org>
  11. Date: Mon, 4 Jan 1993 18:49:00 GMT
  12. Lines: 81
  13.  
  14. In article <1992Dec31.014719.22174@nosc.mil> psm@nosc.mil (Scot Mcintosh) writes:
  15.  
  16. > I'm implementing a data communications protocol that has some data
  17. > structural features that don't look possible to implement in Ada.
  18. > Perhaps someone more experienced can suggest a way to accomplish
  19. > what I'm trying to do (changing the protocol is not an option).
  20. > 
  21. > A Transmission Unit looks like:
  22. > 
  23. > +---------+----------+-----------+------+
  24. > | Packet  |  Packet1 |  Packet2  | etc  |
  25. > | Length  |          |           |  ... |
  26. > +---------+----------+-----------+------+
  27. >     |     |<-------->|<--------->|
  28. >     |          ^          ^
  29. >     |          |          |
  30. >     |__________|__________+
  31. > 
  32. > 
  33. > Each Packet looks like:
  34. > 
  35. > +---------+----------+--------------+
  36. > | Data    |  Data    |  Padding     | 
  37. > | Length  |          |(i.e. nothing)| 
  38. > +---------+----------+--------------+
  39. > |   |     |<-------->               |
  40. > |   |          ^                    |
  41. > |   |          |                    |
  42. > |   |__________|                    |
  43. > |                                   |
  44. > |<--------------------------------->|
  45. >     Packet Length
  46. > 
  47. > For a given transmission, the Packet Length is fixed, but can be
  48. > different in the next transmission. The Data Length within each
  49. > Packet can be different for each Packet. 
  50.  
  51. In article <SDL.92Dec31182221@rigel.linus.mitre.org>, sdl@linus.mitre.org (Steven D. Litvintchouk) writes...
  52. > 
  53. >You didn't happen to state how you know when you have read in all the
  54. >packets for a given Transmission Unit--is there some
  55. >"end-of-transmission" indicator?
  56. > 
  57. >You didn't happen to state how "data length" is related to "data".
  58. >I'll assume that "data" is in the form of a stream of bytes; and
  59. >that "data length" and "packet length" are two-byte integers giving
  60. >the number of bytes in Data and Packet, respectively.
  61. > 
  62. >   type BYTE is range 0 .. 255;
  63. >   for BYTE'SIZE use 8;
  64. >   subtype DATA_BYTE is BYTE;
  65. > 
  66. >   type LENGTH is range 0 .. 50000;      -- or whatever
  67. >   for LENGTH'SIZE use 16;
  68. > 
  69. >   DATA_LENGTH, PACKET_LENGTH:  LENGTH;
  70. >    
  71. >I suggest it's easier to simply define everything as an
  72. >undifferentiated stream of bytes, and use UNCHECKED_CONVERSION to
  73. >extract the more complicated, higher-level structure after you read in
  74. >the needed bytes.
  75. > ... 
  76. >So you can read the first two bytes, and then use UNCHECKED_CONVERSION
  77. >to convert it to the integer type LENGTH.  Then that's the Packet
  78. >Length; you know you must read in that number of bytes for each
  79. >subsequent packet.  So for each subsequent packet, read in a number of
  80. >bytes given by Packet Length; use UNCHECKED_CONVERSION to convert the
  81. >first two bytes to an integer (which represents Data Length); then
  82. >process that number of subsequent bytes as Data, ignoring the rest.
  83. > 
  84.  
  85. This is a valid way to PROCESS the data, but it is not a way to REPRESENT the
  86. data structure. I tried a couple approaches involving unconstrained arrays, but
  87. since the max length of a packet is specified at run time, it cannot be static.
  88. Thus this structure is not REPRESENTABLE in Ada. As an Ada advocate, my
  89. reaction to this is twofold; first, there is probably a better data structure
  90. that is representable. Second, at least Ada can process the data in a
  91. reasonable way; maybe actually representing the structure is not required.
  92. There are certainly other applications (complex cross-linked lists) where the
  93. actual structure is only partly represented by Ada types.
  94.  
  95.