Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > C to Java socket input question

Reply
Thread Tools

C to Java socket input question

 
 
Richard
Guest
Posts: n/a
 
      07-17-2003
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote...
>
> Richard wrote:
> > (E-Mail Removed) wrote...

>
> >>Richard wrote:

>
> >>>My input is basically a stream of 32-bit unsigned integers (e.g., the
> >>>low-level form of IP addresses) along with the occasional fixed-
> >>>length char array.

>
> >>Treat it as a 4 byte array. InetAddress.getByAddress() wants a byte[]
> >>anyway.

>
> > Sorry for being brain-dead, but will he be able to do arithmetic on
> > it if it's in a 4-byte array? As in: unsigned char fbarray[4] ; ?

>
> No, but why do you want to do arithmetic on IP addresses?


The ints aren't exclusively IP addresses. See above; I'm passing 32-
bit integers (the "e.g. the low level form of IP addresses" means
"for example, ... IP addresses").

> (Actually, he can do arithmetic on byte arrays, but it's tedious as all
> get out.)




--
For email, put NOT SPAM in Subject or I'll probably miss it.
<><
 
Reply With Quote
 
 
 
 
Mark McIntyre
Guest
Posts: n/a
 
      07-17-2003
On Thu, 17 Jul 2003 04:21:41 GMT, in comp.lang.c , David Zimmerman
<(E-Mail Removed)> wrote:

>
>No, but why do you want to do arithmetic on IP addresses?


iteration over IP blocks for instance.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
 
Reply With Quote
 
 
 
 
Jon A. Cruz
Guest
Posts: n/a
 
      07-18-2003
Thomas G. Marshall wrote:
> I always wondered if they intended to have IP addresses for all machines in
> the visible universe with that 128 bit thing. But I'm all for it.
>


Ummm... yup. They do.




http://www.ipnsig.org/home.htm

 
Reply With Quote
 
Nigel Wade
Guest
Posts: n/a
 
      07-18-2003
>
> Jon A. Cruz wrote:
>>
>> Text is for people, computers can deal with more.
>>


> Thomas Gagné wrote:


> If the question had come from a computer I might have suggested it use
> something more. But since people are involved text is still preferable.
> Will
> it be a machine debugging the code?


Of course it will, how would you intend to execute the code?

> Will it be a machine translating the
> network-ordered bytes into integers?


Of course it will, or did you think they intended to do it by hand?

> Will it be a machine snooping
> network packets wondering why the message aren't being
> assembled/disassembled properly?


I rather think so, how do you intend to snoop the values otherwise?
Are you able to read packets without one?

>
> You're right, machines are capable of more so humans must depend on them
> to do more, like translate scalar values into text so we can read them, or
> format them into XML so we can both read and understand their format by
> reading them.


So use it for that. When you want to look at the values as text, use the
machine to convert them for you. But when the data is being sent
machine-to-machine text is inappropriate unless it's actually text that is
being transferred. The extra network overhead of sending text instead of
binary is totally unnecessary, as is the CPU overhead of converting every
number to and from text at either end.

I presume you don't send much data over networks.

>
> Not using text is a good approach for job security.


Sorry, but that is rubbish.


--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : (E-Mail Removed)
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
 
Reply With Quote
 
Tukla Ratte
Guest
Posts: n/a
 
      07-18-2003
On Thu, 17 Jul 2003 04:19:33 GMT, David Zimmerman
<(E-Mail Removed)> 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.

--
Tukla, Squeaker of Chew Toys
Official Mascot of Alt.Atheism
 
Reply With Quote
 
David Zimmerman
Guest
Posts: n/a
 
      07-19-2003


Tukla Ratte wrote:
> On Thu, 17 Jul 2003 04:19:33 GMT, David Zimmerman
> <(E-Mail Removed)> 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?

 
Reply With Quote
 
Jon A. Cruz
Guest
Posts: n/a
 
      07-19-2003
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.

stdint.h helps now.

floats in IEE754

XML is probably a poor choice for that.

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

 
Reply With Quote
 
xarax
Guest
Posts: n/a
 
      07-19-2003
(E-Mail Removed) (Tukla Ratte) wrote in message news:<(E-Mail Removed)>...
> On Thu, 17 Jul 2003 04:19:33 GMT, David Zimmerman
> <(E-Mail Removed)> 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.


I use a custom program generator that reads an XML specification
file that describes the various message packet types. The program
generator then spits out Java classes and C source files for each
message packet type.

Each message packet has a fixed length header that includes:

a. A 4-byte magic number for verifying that the byte stream
consists of message packets that I expect.

b. A 4-byte transaction ID number.

c. A 4-byte version number (another constant for sanity checking).

d. A 2-byte message type number that includes a "reply flag"
that indicates whether this is an original message, or a reply
to an earlier message (with the same transaction ID).

e. A 2-byte message length that must correlate to the known
message length for the message type (another sanity check).

If the header portion doesn't match expected values (i.e.,
the sanity checks fail), then the TCP/IP socket is closed
(causing a reset condition on the other side).

If the message packet also has payload data fields, then
those fields follow the header.

The generated Java code has a class for each message type.
The class knows how to read/write a message packet using
the java.nio.ByteBuffer class, which has built-in support
for Big Endian vs. Little Endian byte ordering. (My application
uses Big Endian.) The java class has getter/setter methods
for each field in the message packet.

The generated C code has header files that define a C struct
for mapping the message packet, and source files for each
message packet. The source file for a message packet has
functions for getting/setting each field in the buffer.

Neither the Java or C application code refer directly
to the packet fields, but rather use the getter/setter
routines. This extra level of indirection makes the
application more readable and easier to maintain.

I also have GUI front-end for specifying the message
packets, which generates the XML specification file and
invokes the program generator. I then compile the sources
and rebuild the application. Very simple and reliable.

This design removes any knowledge of the "other side of
the TCP/IP pipeline". Each side doesn't know whether it's
talking to a Java or a C application on the other side,
and it doesn't need to know.
 
Reply With Quote
 
Steve Horsley
Guest
Posts: n/a
 
      07-19-2003
On Fri, 18 Jul 2003 21:50:41 +0000, Tukla Ratte wrote:

> On Thu, 17 Jul 2003 04:19:33 GMT, David Zimmerman <(E-Mail Removed)>
> 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.


Have you considered TCP/IP? It provides a byte stream. Bytes in one end,
same bytes out the other end - no loss and no re-ordering. This is
probably exactly what you need.

Steve

 
Reply With Quote
 
Jos A. Horsmeier
Guest
Posts: n/a
 
      07-19-2003
"Richard" <(E-Mail Removed)> wrote in message news:(E-Mail Removed).. .

> Level: Java newbie, C experienced
> Platform: Linux and Win32, Intel
>
> Another programmer and I are working on a small project together.
> He's writing a server process in Java that accepts input from
> processes I've written over a TCP connection. My processes are all
> written in C; his are all done in Java. He's new to Java, and I've
> never really used it.
>
> My input is basically a stream of 32-bit unsigned integers (e.g., the
> low-level form of IP addresses) along with the occasional fixed-
> length char array.


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.

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.

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);
}

where the 'write(buf)' call simply writes a bunch of bytes. The other
side (the C side) simply reads the chars and stores them somewhere.
Sending strings (char[]s) from the C side to the Java side is easy
too. Simply read a bunch of bytes in a Java byte[] buf and create
a new Java String as follows:

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

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.

Of course you still have to design a little protocol, say, sending
the length of the next datum first (using those htonl() thingies
on the C side and using the simple DataOutputStream object on the
Java side), but that is left as an exercide for the reader.

kind regards,

Jos
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Steve Holden Python 1 02-03-2009 06:20 AM
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Steve Holden Python 0 02-01-2009 12:45 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 0 02-01-2009 07:37 AM
socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 1 01-27-2009 05:05 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48,'Address already in use') Jean-Paul Calderone Python 0 01-27-2009 01:41 PM



Advertisments