Endian problems - what best way to solve it with least effort

Endian problems - what best way to solve it with least effort

[Anh Vo]

I have an application previously running on Big Endian machine communicating with a client simulator through socket. This client is coded in Java running on a separate machine. The data exchanged between them have different structures down to bits and bytes.

Currently, this application is being ported to GNAT running on RH 5.4 (Little Endian PC machine). As the result, both application and client do not communicate correctly any longer due to endian mismatched. The reason is that Java VM uses Big Endian format even though the client runs on a PC.

So far, I have come up with a couple ways. However, each of them involves lots of efforts.

What is the best way to solve it with least effort? Thank you in advance for your suggestion.

Anh Vo

Re: Endian problems - what best way to solve it with least effort

[Dmitry A. Kazakov]

On Tue, 13 Mar 2012 11:00:51 -0700 (PDT), Anh Vo wrote:

> As the result, both application and client do
> not communicate correctly any longer due to endian mismatched. The reason
> is that Java VM uses Big Endian format even though the client runs on a PC.

You should implement the protocol in a machine-independent way, which is
quite simple to do in Ada: you read octets from the socket and compose
objects as you proceed. You define operations like Get_Unsigned_16 and
implement them (2-3 lines of code). On top of these you define further
operations etc.

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

Re: Endian problems - what best way to solve it with least effort

[Marc C]

On Tuesday, March 13, 2012 1:00:51 PM UTC-5, Anh Vo wrote:
> I have an application previously running on Big Endian machine communicating with a client simulator through socket. This client is coded in Java running on a separate machine. The data exchanged between them have different structures down to bits and bytes.

> What is the best way to solve it with least effort? Thank you in advance for your suggestion.

Depending on your performance requirements and the complexity and variety of data structures are being exchanged, consider marshalling/demarshalling using strings--embedded in an XML or JSON carrier.

Marc A. Criley
Ada sub-reddit moderator
(http://www.reddit.com/r/ada)

Re: Endian problems - what best way to solve it with least effort

[Simon Wright]

Anh Vo <anhvofrcaus@gmail.com> writes:

> I have an application previously running on Big Endian machine
> communicating with a client simulator through socket. This client is
> coded in Java running on a separate machine. The data exchanged
> between them have different structures down to bits and bytes.
>
> Currently, this application is being ported to GNAT running on RH 5.4
> (Little Endian PC machine). As the result, both application and client
> do not communicate correctly any longer due to endian mismatched. The
> reason is that Java VM uses Big Endian format even though the client
> runs on a PC.

Was the previous version in Ada? I presume so or you'd have a
translation effort with would already be non-minimal.

What was the previous code like? A sample from a shortish message would
help! 

If it just used Streams there might be a simple approach; in the Ada RTS
adainclude/ there's a file s-stratt-xdr.adb (possibly s-strxdr.adb),
which does stream formatting in network (b-e) order as you require.

You should be able to put a copy of this file in your Ada source path as
s-stratt.adb and recompile with the -a flag to gnatmake.

I'm not sure whether gprbuild supports -a.

Don't use the -f flag unless you want to rebuild the whole RTS!

Re: Endian problems - what best way to solve it with least effort

[Anh Vo]

On Tuesday, March 13, 2012 11:35:34 AM UTC-7, Simon Wright wrote:
> Anh Vo <anhvofrcaus@gmail.com> writes:
> 
> > I have an application previously running on Big Endian machine
> > communicating with a client simulator through socket. This client is
> > coded in Java running on a separate machine. The data exchanged
> > between them have different structures down to bits and bytes.
> >
> > Currently, this application is being ported to GNAT running on RH 5.4
> > (Little Endian PC machine). As the result, both application and client
> > do not communicate correctly any longer due to endian mismatched. The
> > reason is that Java VM uses Big Endian format even though the client
> > runs on a PC.
> 
> Was the previous version in Ada? I presume so or you'd have a
> translation effort with would already be non-minimal.
> 
> What was the previous code like? A sample from a shortish message would
> help! 
> 
> If it just used Streams there might be a simple approach; in the Ada RTS
> adainclude/ there's a file s-stratt-xdr.adb (possibly s-strxdr.adb),
> which does stream formatting in network (b-e) order as you require.
> 
> You should be able to put a copy of this file in your Ada source path as
> s-stratt.adb and recompile with the -a flag to gnatmake.
> 
> I'm not sure whether gprbuild supports -a.
> 
> Don't use the -f flag unless you want to rebuild the whole RTS!

Thank you all very much for your reply. 

Our team has decided to modify Java side due to less effort is involved. In addition, the Little Endian conversion utility is used. I will update the result once it is completely tested.