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

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

David Bolen wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
> > Bart.Vanhauwaert@nowhere.be wrote:
> (...)
> > > I have never felt the need to know the size of a certain struct. Why
> > > don't you give an example where it is needed?
> >
> > What? You've never written a structure to a file? A socket? A message queue?
> 
> To piggy back on this slightly to ask a related question - I'd
> normally say "no" to your question because a direct write of a
> structure in any of those situations would be non-portable in most
> languages/libraries I've used, except when using an official
> standardized marshalling interface for such I/O, in which case the
> overall structure size is generally unimportant.  Instead you'd want
> to define what needs to be marshalled on a field by field basis or in
> dynamic situations let introspection handle it.

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.

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.

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

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.

> 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.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg