Re: JGNAT, Byte arrays, and Stream_Element_Arrays

["Marc A. Criley" <mcquadex@earthlink.net>]

Stephen Leake wrote:
> 
> "Marc A. Criley" <mcquadex@earthlink.net> writes:
> 
> > Based on some past work I did with tying Streams and their
> > associated attributes together with sockets, I've attempted to adapt
> > that code to work with Java's sockets, hence the work with
> > byte_Arr(ays). I've had partial success, at least with the specific
> > data streams with which I'm working.
> 
> Now I'm confused. Why use "Java's sockets" if you are attempting an
> "all Ada" approach. I guess you mean "use a Java 2 socket class",
> because there is no equivalent Ada package?

Yes, I'm using Java's socket class for the socket communications.  (Keep
in mind that while I'm writing Ada, it's _all_ being compiled into Java
Byte Code.)  Socket packages written in Ada (such as Tardieu's
AdaSockets, which is used on the server) at some point import and invoke
OS functions, so those are not usable unless I wanted to go the JNI
route--which I don't.

> > I did discover that I had to reverse the order of the bytes, at
> > least on a PC linux platform--so as it turned out that pretty much
> > ruled out the possibility of bulk conversion anyway.
> 
> Hmm. This implies you are attempting to send structured data as stream
> of bytes, and some of the data is multibyte (eg 16 bit integers), and
> one side of the stream interface is converting to network byte order
> but the other side isn't. Now I'm really confused! Or are the client
> and server different machines with different native byte order?

Yes, I am sending structured data as a stream of bytes, and yes, one
side of the interface (the JVM client) is converting the data to network
byte order.  For now, both client and server are running on the same
PC-Linux box.

> > Plus, JGNAT's implementation of some of the Stream attributes, like
> > 'Input, seems a little shaky. Sometimes doing a String'Input of data
> > freezes up, even though the data was of course sent via
> > String'Output.
> 
> Certainly if one side is doing conversions to network byte order and
> the other isn't, you will have problems. The string length will be
> wrong, for one.

No, even after the conversion problem was taken care of, JGNAT still
sometimes has problems correctly processing stream attributes.  I was
monitoring the data at the byte level as it came in, and there was
nothing wrong with it.  The JGNAT generated code simply froze up in some
instances.  (Same location each time, so it wasn't random with each
run.)

> Ah. So you have native (what machine?) Ada code generating a stream
> from structured data, but then you are reading that stream with a Java
> stream library. Sounds like a recipe for trouble. What does JGNAT do
> for Ada.Streams? Maybe that's what you are using. I seem to recall
> that the JVM spec defines byte order in streams.
> 
> Ada makes no guarrantee that a stream written by one compiler/machine
> will be readable by a different compiler/machine. Here you have
> GNAT/PC (I guess) writing, and JGNAT/JVM reading, so it is allowed to
> not work.

I am very much aware that I'm playing close to implementation and
platform dependencies :-)  And that the solutions I come up with may not
be portable across platforms.  But I had to start banging my head
against the wall somewhere :-)

> You need to use the Distributed Annex facilities to make this work
> properly (never used them myself, so I can't help more).

The idea of trying to get the DSA to work with a natively compiled
server and a JVM client scares me even more than using the Java sockets
class!

> --
> -- Stephe

And by the way, got the whole thing happily working.  Had to step out
and do the "Engineer's Dance"!

Marc