views:

559

answers:

2

I am an intern who has inherited a problem with a testing program at the place where I am working. After searching around on a little bit I can across a person with my exact same problem. After asking around a little bit here, i found out that the guy who posted this does actually still work here, and I am getting his help with this too, but I think he explains the problem a little more sussinctly than I do.

on this forum

Here is the jist of it for those of you who don't want to read all that garbage. We have a GUI that runs on the client side and makes remote calls to a test application written in Ada that runs on a SPARC Unix machine. When everyone in the building used Unix machines to do everything, the test app and gui worked just fine, but recently everyone got newer faster linux x86 machines.

Anyone who got the upgrade isn't able to run the test app because of the Big / Little Endian incompatibility between the test app and the GUI.

Now, it's my job to figure out how to fix it. Now, I know there is going to be kind of a big app rewrite here, and I'll probably have to redefine how the GUI and the test app talk to each other, but how can I do this without completely disassembling the program?

A few of the options I came up with myself are as follows: Java RMI XML/RPC SOAP Data Baking?

Keep in mind, I'm a total noob to network programming and even though these "solutions" may look valid to me, I may be completely off base. Please help!

+1  A: 

You don't need to rewrite anything. Just make sure you use network order (big endian, the way you naturally express numbers) on both sides. x86 uses little endian, so you have to look at the source code of any application failing on x86.

Then, call htonl/htons/ntohl/ntohs (see man 3 htonl) or a similar function to convert every number you send/receive to the correct encoding in the portions of code that send/receive data. Java always uses network order, so you don't have to worry about native Java code.

phihag
Thanks for the answer! Unfortunately I am now more confused now though. The Java is running on the LE machine, and the Ada code is running on the BE machine, so everything should be working out.Back to the drawing board I guess.
@Andy Does the Java code use JNI? Are you sure that endianess is the problem? If so, you should be able to tell us what endianess is used on the wire. My advice: Use wireshark and debuggers on both sides and ask someone who is familiar with the network components of GUI and server.
phihag
@phihag I'm pretty sure JNI isn't used, and I'm not 100% sure endianess is the problem. I learned of this problem from the last guy to work on it. Thanks for the suggestions. I'll definitely try to set that up and see what I can figure out.
...which means one side has to be rewritten.
T.E.D.
@T.E.D. If the network components are decent. there's no rewrite needed, just a small modification in the integer serialization.
phihag
Well, now we are arguing semantics. I think we are both saying that *something* new has to be written in one side or the other, but not every line of code, yes?
T.E.D.
A: 

You are looking at a really heavy solution. (FYI: Another similarly heavy solution is ASN.1).

All you really need to do is add code on one side (probably the test app) to perform byte swapping on the incomming data.

The tricky part of course is that you can't (generally) just swap bytes. You have to know what the data is, because two 2-byte integers need to get swapped differently than a single 4-byte integer at the same address would be. Character data doesn't get swapped at all.

Possible Easy Solution: If you are using Gnat as your Ada compiler, one option would be to rewrite the data transmission code to use streams (if it isn't done that way already), and write some Ada code on the Linux end to read it using streams. Then fix your compilers to use the XDR version of Ada streams (explained in more detail here and here. The XDR version of Gnat's streams handle byte-swapping automaticly.

T.E.D.