Gnat Sockets & Streams

Gnat Sockets & Streams

[Robert Love]

I've a problem with the Gnat.Sockets that is driving me crazy.  I have 
to use multicast to announce a service is available.

I've looked at the example program given in g-socket.ads and compiled 
in and it runs just as expected.  I've extracted the multicast portion 
and split into two programs and compiled on different machines  and it 
communcates the string stream just as expected.

When I insert this code into my actual program it works differently.  
The string comes over 1 character at at time.  I've looked over the 
code to see that I used the package exactly like the example.  I've had 
coworkers look it over.  We don't see any way the

  String'Output(Channel, "Dummy Data");

can output the data one character at a time.    The Output is in a loop 
and I would expect to see

Dummy Data
Dummy Data
Dummy Data

instead of

D
u
m
m
y

D

by the receiving program.  I've also used tcpdump to see that the 
packet really contains just one character instead of there being a 
problem with the receiving progam.

Is there  any way a stream can be corrupted?  Any settings parameters I 
could compile with that change the behavior?

Any comments appreciated.

Re: Gnat Sockets & Streams

[Simon Wright]

Robert Love <rblove@airmail.net> writes:

> I've a problem with the Gnat.Sockets that is driving me crazy.  I have
> to use multicast to announce a service is available.

> When I insert this code into my actual program it works differently.
> The string comes over 1 character at at time.  I've looked over the
> code to see that I used the package exactly like the example.  I've
> had coworkers look it over.  We don't see any way the
>
>  String'Output(Channel, "Dummy Data");
>
> can output the data one character at a time.    The Output is in a
> loop and I would expect to see
>
> Dummy Data
> Dummy Data
> Dummy Data
>
> instead of
>
> D
> u
> m
> m
> y
>
> D
>
> by the receiving program.  I've also used tcpdump to see that the
> packet really contains just one character instead of there being a
> problem with the receiving progam.
>
> Is there  any way a stream can be corrupted?  Any settings parameters
> I could compile with that change the behavior?

That is, I believe, the behaviour specified by the ARM[1], paras 25..27
and 9.

This happened to me a long time ago, I thought AdaCore had implemented
an optimisation for strings.

You could try writing a new String and overriding 'Write (shouldn't need
to override 'Output, but maybe ...)

[1] http://www.ada-auth.org/standards/12rm/html/RM-13-13-2.html

Re: Gnat Sockets & Streams

[Dmitry A. Kazakov]

On Fri, 14 Sep 2012 21:01:00 -0500, Robert Love wrote:

> We don't see any way the
> 
>   String'Output(Channel, "Dummy Data");
> 
> can output the data one character at a time.

It could do this in any way and any combination of characters per
definition of stream. AdaCore changed the behavior of array stream
attributes, I heard. But, still, it is perfectly legal in any way.

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).

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.

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.

> Is there any way a stream can be corrupted?

There is nothing corrupted in the described behavior.

> Any settings parameters I could compile with that change the behavior?

See above. 

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

Re: Gnat Sockets & Streams

[Simon Wright]

"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.

> 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.

> 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).

[1] http://booch95.svn.sourceforge.net/viewvc/booch95/trunk/src/bc-support-memory_streams.ads?revision=1420&view=markup

Re: Gnat Sockets & Streams

[Robert Love]

On 2012-09-15 17:02:34 +0000, Simon Wright said:

> "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.
> 
>> 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.

This is my situation.  My Ada has to talk to Python or C.


> 
>> 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.


I'm not sure I want to adopt the Booch Components just to get a packet 
sent correctly.

Thanks to all for your comments.


> 
> Not sure why it would matter for TCP? (unless you've used TCP_NO_DELAY,
> of course).
> 
> [1] 
> http://booch95.svn.sourceforge.net/viewvc/booch95/trunk/src/bc-support-memory_streams.ads?revision=1420&view=markup 
> 

Re: Gnat Sockets & Streams

[Dmitry A. Kazakov]

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

Re: Gnat Sockets & Streams

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 15 Sep 2012 18:02:34 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>>> 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.

Well, I'd have thought that the it would be OK to say

* we need to transfer <data>
* we need a protocol, would <what we know stream attributes do> be OK?
  - yes, go with stream attributes
  - no, declare a data-specific protocol

because I doubt that, for instance, a protocol for strings would first
pass the lower & upper bounds! you'd much more likely pass the
length. So the stream attributes wouldn't meet the predefined protocol;
and you've committed to work that might not have been necessary.

But I do agree that you have to be sure that the stream attributes will
suffice.

Re: Gnat Sockets & Streams

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Robert Love <rblove@airmail.net> writes:
>
>> The string comes over 1 character at at time.  I've looked over the
>> code to see that I used the package exactly like the example.  I've
>> had coworkers look it over.  We don't see any way the
>>
>>  String'Output(Channel, "Dummy Data");
>>
>> can output the data one character at a time.
[...]
> That is, I believe, the behaviour specified by the ARM[1], paras 25..27
> and 9.
>
> This happened to me a long time ago, I thought AdaCore had implemented
> an optimisation for strings.

As far as I can tell, they have (GCC 4.6/4.7, GNAT GPL 2011/2012).

I was outputting to an instrumented memory stream, but I don't see how
that would make a difference.

I wrote

   String'Output (Str'Access, "hello");

and received 4 bytes (lower bound), 4 bytes (upper bound), 5 bytes
("hello").

Re: Gnat Sockets & Streams

[gautier_niouzes]

If the one byte or character at a time transfer is an issue, here is a solution:

http://unzip-ada.sf.net/za_html/zip__adb.htm#653_13

HTH...
_________________________ 
Gautier's Ada programming 
http://freecode.com/users/gdemont