Re: Gnat Sockets & Streams

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 15 Sep 2012 18:02:34 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
> (from bitter experience communicating with many different device
> types/protocols)
> 
>> Using streams and sockets you should remember:
>>
>> 1. Stream attributes are not portable. The only type you should read/write
>> into the socket stream is Unsigned_8 or equivalent (octet).
> 
> But you are not likely to have much trouble if you use the same
> compiler, and ideally the same version, on either side.

Yes, but why gamble?

>> 2. As with any I/O you should honestly implement all layers of the protocol
>> at hand. Don't try shortcuts like stream type attributes, representation
>> clauses etc.
> 
> The stream type attributes may well be OK, and (as above) if you have
> the same compiler either end you will probably be OK. It's quite another
> matter if your Ada has to talk to someone else's C.

I argue that this is not solid engineering. Even if two Ada programs are to
communicate, the protocol must be fully specified first. The
implementations must conform that specification. If a stream attribute
indeed implements the specification, fine, the code should document that
and explain why. What I am strongly against is that sort of upside-down
design, when people implement something first and then declare that the
would-be protocol is what the stuff accidentally happens to do. 

>> 3. Network protocols are packet-oriented. You have to use Write (of the
>> type Root_Stream_Type) instead of attributes to ensure that the packet is
>> sent as a whole. It matters for both UDP and TCP/IP.
> 
> This is SO TRUE for UDP. I've never used multicast but anywhere there
> are datagrams you need to heed this!
> 
> The approach we adopted was to use a memory stream (eg [1]) and then use
> Write on the resulting Stream_Element_Array.
> 
> Not sure why it would matter for TCP? (unless you've used TCP_NO_DELAY,
> of course).

Yes, mainly to have it NO_DELAY-agnostic.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de