From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-65-14.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-3.2 required=3.0 tests=BAYES_00,NICE_REPLY_A,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
Path: eternal-september.org!reader01.eternal-september.org!news.szaf.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Sockets, Streams, and Element_Arrays: Much confusion
Date: Sun, 1 Jan 2023 18:17:07 +0200
Organization: Tidorum Ltd
Message-ID: <k1dq03F95j7U1@mid.individual.net>
References: <top8uc$cqv$1@gioia.aioe.org> <lyo7rjpj5w.fsf@pushface.org>
 <6183be57-2796-0ab7-739f-a5b557083ee6@gmail.com>
 <toq5ag$aks$1@gioia.aioe.org> <lyk027p2eg.fsf@pushface.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net Hgtqgain+jdZ1hNV5Gf+EwfIQJmTdET0EoKaAzhlO0Fu/+6lw4
Cancel-Lock: sha1:IFjaVRDvFwLxmyfjjcN7XafKP7c=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:102.0)
 Gecko/20100101 Thunderbird/102.6.1
Content-Language: en-US
In-Reply-To: <lyk027p2eg.fsf@pushface.org>
Xref: reader01.eternal-september.org comp.lang.ada:64764
List-Id: <comp.lang.ada>

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.