Re: How Ada could have prevented the Red Code distributed denial of service attack.

[David Bolen <db3l@fitlinxx.com>]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

(The end of the post does answer my question, so feel free to skip to
there to avoid some intermediate discussion :-))

> Are you suggesting that every binary file that you've ever done I/O
> on, is don'e in a perfectly portable fashion? Really? I rather 
> doubt it, because I've seen a lot of code in the form of Open
> Sourced projects that do just that.

Well, I'm not sure what "a lot of code" in open source projects
necessarily has to do with assumptions about my own code.

To answer your question, yes, that's how I do it.  Virtually all of my
development for the past decade+ has been networking and I'm rarely
involved in a homogenous environment (systems, tools, etc...), so as
it happens portability is ingrained in everything I do.

In fact, that's also why I prefer non-binary formats whenever possible
(unless pre-supplied portable or standards-compliant marshallers are
already available).  I find that the portability afforded by textual
formats is generally an easy trade-off for any efficiency loss.

But that's really an aside unrelated to the question I was asking.  I
wasn't looking to justify why you would take one approach over the
other, but just looking for information about how Ada handles
structure I/O.

> For example, if you were to write cpio, excluding the portable format
> (-c), are you not going to write the binary header out directly?
> Sure you are.  You don't have to of course, but this is different
> from general experience.

I'm not sure if you mean writing the full binary header as a structure
in one shot, or just writing binary data in the header.  I'd have less
of a problem with the latter than the former - although doing the
former does get to my question about Ada's structures, e.g.,
consistency of packing, compatibility across platforms and compilers.

In my case, when I do use binary data/headers, I ensure that I stamp
them with the endian-ness in which they were written.  This yields
best performance in the native environment, but permits portability.
This is the same approach, for example, that the bsddb library takes
for its meta data.

Note that cpio is a good example because only the oldest (declared
obsolete, albeit often still the default) formats used a binary
header.  All of the recent formats have been portable, and in fact,
often the headers are in ASCII.  And at a minimum, on reading, the
binary format has magic values in it that permits detection of
endian-ness.  It's awfully rare to have an archive format (whether it
be tar, zip, or whatever) that doesn't take portability into account.

> EVEN IF YOU IGNORE FILEs, you don't have portability concerns when
> you write to pipes, UNIX sockets (ie. local to the same host), 
> call msgsnd() and msgrcv() for message queues. These do not require 
> any endian issues because you're talking to processes within the 
> same host. It would simply be a _waste_ to write to your  
> process on the same host, in an endian neutral way (depending 
> upon the endian orientation).

This shifts to an endian focus when that was really only part of my
original question.  I may not have endian concerns with local I/O but
I could certainly have larger structure alignment concerns between two
communicating applications.

In the Ada case, would writing a structure to one of those constructs
then be readable (as a complete structure) from the other end with
code written with another Ada compiler from a different vendor?

> In all of these cases, you'll want to know what the "real"
> length is. Of course, you could take the "I don't care about a
> byte or two of extra waste", and depending upon the situation, 
> I might agree.  I only point out, that in C/C++, that these
> issues do arise in practical situations.

Yes, but the "real" length you want to know for the purpose of the I/O
is "on the wire", and not necessarily in-memory.  Of course, you might
want to know both lengths, but it's the wire length that matters for
the communication I/O.  And wire length versus memory length may not
be the same, so you don't necessarily want to base the former on a
query of the latter.

> > Does Ada support simply performing I/O on such structures to
> > constructs as files, sockets or message queues in a portable way
> > (without explicit marshalling), such that some other Ada application
> > (even with a different compiler and/or platform) would receive the
> > structure intact?
> 
> It can, as can C++. But not out of the box. In Ada, you can 
> define how the object is read or written. Ada's streams work
> differently than C++'s streams, but the ideas are similar.
> 
> There is however, another "distributed systems annex?", to 
> which I must confess ignorance of 
> at the moment (I have not yet tried it), that does the equivalence 
> of RPC (or at least I think GNAT does it this way).
> 
> Now I am not certain of this point, but it is _likely_, though 
> probably not guaranteed, that XDR formats will be used for this 
> (big endian format, portable etc.) But please don't quote me on
> this, since this particular answer is entirely _wild_ _speculation_ 
> on my part. Someone with more Ada experience can help us out on 
> this point, if they are willing.

Thanks - that's really what my question was aimed at.  While having
such an XDR (or XDR-like) definition in an Annex would bring that into
the Ada specification, it sounds like handling this with Ada is pretty
close to how its handled in other situations.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/