little endian and big endian

[Ravi Danum]

Hello,

I have written some java client code to connect to a router.  The router sends my client message to an application.  From time to time, the application either refuses connection or closes the existing connection. There is other client code that has been written in Python which does not cause this problem.  I am using Wire Shark to look at the messages.  The messages look fine.  I am wondering if I need to change my client code, written in Java to little endian.  Both clients and the application are all on the same machine.  None of the other code is written in Java, meaning the application.

Does anyone have an idea how to check for this or correct this?  Could the problem be something other than the endian?

Many thanks.

Ravi

[Jim Venolia]

I would guess your problem has more to do with Java's lack of an unsigned byte than endianness.   IMHO, that is the major failing of Java (90% of everyone here will disagree with me here, but they don't deal with bitstreams/hardware registers).

[Tim Holloway]

Network protocols are designed to avoid problems with "endian-ness". IBM dominated the computer arena up until about the mid 1980s, and it was "big-ended" (MSB first). As far as I know, the other "seven dwarfs" of the industry were likewise big-ended.

It was DEC that made the little-end approach popular. Why they did it, I have no idea - probably made manufacturing cheaper to a more cost-sensitive market - but when Intel started making microprocessors, they did likewise.

I don't care for little-end myself. It's a bytewise-discontinuous mode, which wreaks havoc on memory-to-memory bitwise operations and comes in at least 2 sub-flavors when you start talking 4-byte words and larger, since you can be byte-swapped within 16-bit parts and "big-ended" for the pairs, OR you can be both byte-swapped AND word-swapped.  

But it's not going away anytime soon.

However, dealing with this mess is one of the reasons why a lot of network protocols are formally specified in ASN.1 notation, which deals with that sort of stuff as a core principle.

If you're getting connections bounced or closed, however, I doubt it's the data format. The parts of the data packets that that layer of the network stack deals with are supplied by the hardware and OS, which already know what order the bits should be in and deal accordingly.

More likely you have a networking problem. Could be bad cabling, flakey router/switch, traffic overload, or a problem with the destination machine (mis-configured networking or application responds too slow).

[Ravi Danum]

Hello,

Thank you for the replies.  I have found that I needed to add:  socket.flush().

I was glad for the post on little vs. big endian.  I will have to work with this on another part of my task.

Ravi

[Matt Wong]

well - I guess you meant OutputStream.flush() or Writer.flush() as Socket dosn't implement Flushable nor provide its own flush() method

flush() solving your issue sounds like a timeout on the remote as your code doesn't finish the message within time - common if somewhere in the chain from Socket.getOutputStream() up to your write() call buffering occurs (get this mostly from apache libs as they poorly implemented (in terms of convinience they try to provide but failing at it))

[Tim Holloway]

Matt Wong wrote:well - I guess you meant OutputStream.flush() or Writer.flush() as Socket dosn't implement Flushable nor provide its own flush() method

flush() solving your issue sounds like a timeout on the remote as your code doesn't finish the message within time - common if somewhere in the chain from Socket.getOutputStream() up to your write() call buffering occurs (get this mostly from apache libs as they poorly implemented (in terms of convinience they try to provide but failing at it))

Or, to put it more concisely, networking isn't done like the old TTY devices where you send out characters all the time. There's a lot of overhead for networking, starting with adding the addresses of the source and destination machines and their ports, and going on from there. So network data is assembled into blocks of data and the blocks are sent.

But the problem with that is that somewhere you have to know when you've got all the data so you can tell when to send the block. For intermediate blocks, there's usually a limit (the Maximum Transmission Unit or MTU), so once you have that many bytes (or octets in network language), the block can be sent. The problem, then, is that the last block may not be completely full. So you have to have something push it out or it will just sit there waiting for more data when there is no more data. That's what the flush() method is doing. Pushing that last block out.

[Ravi Danum]

Thank you both so much for the replies.  I too read that some incomplete blocks may not have been pushed out, so I added the flush to the output stream.

Both answers were helpful in my socket communication.

-Ravi