Re: Sockets, Streams, and Element_Arrays: Much confusion

[Mark Gardner <magardner2017@gmail.com>]

On 31/12/2022 15:11, Dmitry A. Kazakov wrote:
> On 2022-12-31 13:11, Mark Gardner wrote:
> 
>> ...
> 
> Stream_Element_Array is declared in Ada.Streams as
> 
>     type Stream_Element_Array is
>        array(Stream_Element_Offset range <>) of
>           aliased Stream_Element;
> 
> For communication purpose it is an array of octets. Your datagram is 
> represented as a Stream_Element_Array or a slice of.
> 

According to RM 13.13.1, "Stream_Element is mod implementation-defined" 
which to me says there is no guarantee that they will be octets, unless 
this is specified elsewhere?

> As for streams, yes, it does not make sense to use them for networking, 
> unless you override all stream primitives. The reasons for that are
> 
> - non-portability of predefined primitives
> - low efficiency for complex data types
> - encoding inefficiency as well
> 
> You will need to handle some application protocol artifacts, checksums, 
> counters, strange encodings, sequence number etc. It is easier to this 
> directly on the Stream_Element_Array elements.

So, how would I do this directly on the elements? I mean, if it is an 
octet-array to a string, I expect an element-to-element copy, or type 
conversion to work, but what about integers? Do I need to do something like
My_Int:=Unsigned_8(octet(1))+2**8*Unsigned_8(octet(2));
or whatever endianness demands? Or is this the time to learn how to use 
Unchecked_Conversion?

> And, well, do not use UDP, expect for broadcasting. There is no reason 
> to use it. For multicast consider delivery-safe protocols like PGM. For 
> single cast use TCP/IP. (If you need low latency see the socket NO_DELAY 
> option)
> 

  Well, my use case just so happens to be broadcasting, and 
re-broadcasting data across a binary-tree-like p2p network.