Re: Sockets, Streams, and Element_Arrays: Much confusion

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2023-01-01 1:41, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> My advise would be not to do this. It is wasting resources and
>> complicated being indirect when 'Write and 'Read are
>> compiler-generated. If you implement 'Write and 'Read yourself, then
>> why not calling these implementations directly. It just does not make
>> sense to me. I always wonder why people always overdesign
>> communication stuff.
>>
>> Build messages directly in a Stream_Element_Array. Use
>> system-independent ways to encode packet data. E.g. chained codes for
>> integers. Mantissa + exponent for real numbers. If you have Booleans
>> and enumerations it is a good idea to pack them into one or two octets
>> to shorten the packets. All this is very straightforward and easy to
>> implement.
> 
> It has to depend on the design criteria.
> 
> If you need something now, and it's not performance critical, and you
> have control over both ends of the channel, why not go for a
> low-brain-power solution?
> 
> On the other hand, when faced with e.g. SNTP, why not use Ada's 
> facilities (e.g. [1]) to describe the network packet and use
> unchecked conversion to convert to/from the corresponding stream
> element array to be sent/received?
> 
> [1]
https://sourceforge.net/p/coldframe/adasntp/code/ci/default/tree/SNTP.impl/sntp_support.ads


One reason is that the Scalar_Storage_Order representation aspect is 
GNAT-specific, so that code is not really "Ada code", but "GNAT code". 
With most processors now being little-endian, while network traffic is 
still big-endian, byte-endianness conversion is usually necessary.