«

Jon A. Cruz wrote:
> Tukla Ratte wrote:
>
>>
>> I'm also trying to figure out a good way to pass binary data between
>> Java and C (well, C++). Right now, I'm leaning toward Base64 MIME
>> encoding, but I need to see if XML could be of any use.
>
>
> Network byte order.
>
> explicit sizes.

And what sizes should those be? And what happens when something exceeds the
limits of an integer? Should the interface be rewritten?

>
> stdint.h helps now.
>
> floats in IEE754

What if more precision is required and/or demanded? Why not fractions or some
other expression that can be arbitrarily precise?

>
> XML is probably a poor choice for that.

XML or any parsable text-based information would be more flexible than scalar
values. Admittedly they would use more bandwidth but I haven't detected any
bandwidth requirements--just bandwidth anxieties. Perhaps everyone would like
to omit the century from our dates?

Bandwidth increases every year--more programmers should take advantage of
it--unless of course you're sending spam.

>
> (I've been using XML for quite some time. I even use it to make source
> code. Abused, it's bad)
>


--
..tom
remove dashes in email for replies
opensource middleware at <http://isectd.sourceforge.net>

Jos A. Horsmeier wrote:
> I'm hopping in a bit late, but nevertheless. I've implemented something
> similar and, the lazy bones that I am, I just wrapped a DataInputStream
> and DataOutputStream around the raw SocketStream (this is the Java side
> of the story). Those two streams take care of about anything.

Bingo!

That's probably much of why they are as they are.




> If the other side happens to the 'C side' running on some box, all the
> other side has to do is use the htonl(), ntohl() macros and their compadres
> to send/receive binary integer data. Binary byte arrays can be passed
> around without conversion.

Generally, I dislike those macros. First, 'cause macros are bad.
But more because there are some usage problems. On a little-endian
machine, they flip bytes. If one calls something twice, you undo the fix
and break it again. Also, you have to play magic anyway to get the
initial value.

I prefer clean code that just uses bit math to shift things. No macros
needed, and works on any platform regardless of primitive size. Since
you have to play a little code to get the size issue compensated for,
you can easily fix byte order at the same time.



>
> Strings can be passed around using a little trick -- Java characters take
> up 16 bits (the Unicode stuff) while, normally the C side uses char[]s
> to store their strings. (wide characters are a different cup of tea).
> This is how Java Strings can be written to the socket:
>
> void write(String s) {
> byte[] buf= s.getBytes("ISO-8859-1");
> write(buf);
> }

That's probably not good. Mainly because Latin1 (AKA ISO-8859-1) will
loose lots of characters. On a MS Windows platform you will lose 32
places in the visible character range. On a Mac, you'll use 50%.


It's better to use UTF-8 for your wire format.


> String s= new String(buf, "ISO-8859-1");

Here too.


> Double values are easy to send/receive too; simple reverse the byte
> order on the C side before sending and after receiving and simply
> read/write the double on the Java side.

Not quite.

Do that on my Mac G3 and it will be scrambled.

Seriously, though, this is a little tricky. So I think it's a good idea
to add some asserts in the C code.
Assert that sizeof(float) == 32 and that sizeof(double) == 64. Then you
might want to add a simple one to be sure that your platform uses
IEE754. If any of these are not true, then you'll need some platform
specific C code in that case (of course, since IEEE754 became standard
and widespread, that's much easier)

And you want to be sure not to just "reverse" the bytes. Instead you
want to "send them in network byte order". IIRC, this is one of the few
places where I cast a pointer and use htnl.

On Sat, 19 Jul 2003 03:26:24 GMT, David Zimmerman
<> wrote:

>
>
> Tukla Ratte wrote:
> > On Thu, 17 Jul 2003 04:19:33 GMT, David Zimmerman
> > <> wrote:
> >
> >
> >>
> >>Thomas G. Marshall wrote:
> >
> >
> > < snip >
> >
> >>>Then again, you can always use long's (in java these are 64 bits).
> >>
> >>For some reason this always leaves a bad taste for me.
> >
> >
> > Maybe because it doubles your bandwidth requirements?
> >
> > I'm also trying to figure out a good way to pass binary data between
> > Java and C (well, C++). Right now, I'm leaning toward Base64 MIME
> > encoding, but I need to see if XML could be of any use.
> >
> Why not just pass the bytes? Why complicate your life and increase the
> demand on bandwidth?

Yes, you're right.

I looked over my notes this weekend. The Base64 idea was originally
meant to work around endianess issues. For some reason, at that time,
I'd gotten the meaning of "endianess" messed up and thought it meant
how the bits are arranged within a byte, not how the bytes are
arranged in multi-byte value. So that has been nixed.

I was looking into the XML for a way to pass "header" data (filename,
file length, various attributes) along with the binary data itself.
Of course, I don't *need* XML for that; I just thought it might be
more "elegant" and possibly more robust.

My project is a client-server image database. I'm writing it
primarily as a learning experience, and I'm not planning to distribute
it, so it will probably include features that would be bloat in a
"real" project.

--
Tukla, Squeaker of Chew Toys
Official Mascot of Alt.Atheism