So this is a really strange problem. I have a Java app that acts as a server, listens for and accepts incoming client connections, and then read data (XML) off of the socket. Using my Java client driver, everything works great. I receive messages as expected. However, using my C++ client driver on the first message only, the very first character is read to be an ASCII 0 (shows up like a little box). We're using the standard socket API in C++, sending in a char* (we've done char*, std::string, and just text in quotes).
I used Wireshark to sniff the packet and sure enough, it's in there off of the wire. Admittedly, I haven't done the same on the client computer. My argument is that it really shouldn't matter, but correct me if that assumption is incorrect.
So my question: what the heck? Why does just the first message contain this extra prepended data, but all other messages are fine? Is there some little trick to making things work?
This is most likely an encoding issue. If you're just using char * for your C++ client, you're assuming ASCII encoding (at best), while Java uses Unicode (or UTF, I misremember which) internally and emits UTF-8 (IIRC) by default.
Either have your Java server emit 7-bit/character ASCII, or have your C++ client read the encoding Java is emitting.
Ahhh. I'm going to have to spend some time curled up with Google by a fireplace to figure out how to match up the encoding, but that does give me something to go on. I'll probably need to change my Java encoding to match what C++ uses, since that matches the customer scenario. Anyone with a good link, additional info, or code snippet, please post.
If you've got your XML packed as a string, you can use getBytes() to do your encoding:
byte [] asciiEncodedBytes = myString.getBytes("US-ASCII");
EDIT: It's been a while since I've been in Java land, but it doesn't look like Java has any ASCII encoding streams in the core library. I did find this class out there which apparently will wrap an ASCII encoding stream for you. Thankfully it's in an open source project so you might be able to mine the class out of it for your server.
Not that I know of. It's time to binary-search the space of possible culprits.
I would run Wireshark on the client computer to make sure the problem really is originating there. Theoretically some misbehaving router or something could do this (very hard to believe though).
Then I would check the arguments to the socket APIs while the program is actually running, using a debugger.
At that point, if the program is definitely correct and the packets coming out of the computer are definitely wrong, you're looking at a misbehaving networking library or a bad driver.
So, the encoding thing didn't work. In the end, I simply did a substring(startIndex) call on the incoming message using xmlMessage.indexOf("<") as the starting index. It may not be elegant, but it'll work. And the box, will remain a mystery. I appreciate the insight that you three provided.
Related
Good evening,
I am thoroughly baffled by a behaviour that happens with a Java application of mine.
The application is to be used to connect to a web API and download a table of data from there to be further used in academic research.
I was trying to set the export to correct encoding, to save time, I disabled iteration in calls to web API by disabling some methods and removing a variable from a URL string construction - placing an integer 42 in its place.
Upon this, I was surprised to see the correct encoding.
A bit down the road, and I can confirm - if I use this URL:
new URL("http://www.foo.bar/api/unit?id="+scraper.ujList[i]);
where ujList[] is an array of integers,
then the output has typical wrong encoded characters like this ÄŤasĹĄ RuĹľinov
meanwhile, if I use
new URL("http://www.foo.bar/api/unit?id="+42);
then the output is proper, like Ružinov.
I have also tried Integer.toString() as well as String.valueOf() on ujList member, but it didn't help.
FWIW it does not matter if I run a jar file, a class file, or from within Eclipse.
I have no idea how to continue.
I am to develop a mobile application for the Java ME platform that sends SMS messages, containing binary data. However, the application is to use a custom port for sending these messages (so that it can register itself and automatically receive these messages, instead of the standard messaging system of the phone).
My question is:
1) Are BinaryMessages to custom port widely supported in mobile networks worldwide? Or is this something "extravagant" that would work only with a few telecom operators?
2) Normal TextMessages tend to be broken down to multiple parts when their text exceeds the limit of a single message. Are BinaryMessages treated the same way, and if so, how can I deal with this issue (fragmentation) in my application? Obviously part of the message will not do the work and ideally I would like to get the full message when all of its parts are received. Is this dependent on the carrier network?
I realize I could test this out, but I can't run the test on many telecoms, just those in my (small) country, and this is crucial to whether this application should be developed, or not.
I tried looking for the answers by myself, but I failed. Sorry if these are trivial questions and thank you for your time.
I see nothing wrong with this question. I can only offer a semi-answer though.
It is true that it is up to the individual network provider to choose whether they want to keep all ports open, or not. Therefor you cannot assume that it's always possible to send/receive a text message or a binary message.
However, I was told by another JavaME developer long time ago, that it's very unusual for them to close the ports. (Aren't the same ports used for a lot of other protocols such as sockets and http? If yes, then surely they are always open. Closing them wouldn't make any sense).
If I were you I'd add some code to check if messages are sent, and then output some error message to the user about it if it fails. (If possible, also call some URL as a way of error-reporting back to you).
About the broken down messages, that's a good question. I have no idea. I would make some real-device tests to find out.
I have a simple program that makes a request to a remote server running a service which I believe is written in Delphi, but definately running on Windows.
I'm told the service will be using whatever the default encoding is for Windows.
When I get a response and use println to output it I'm getting some strange symbols in the output, which make me think it is a character encoding issue.
How can I tell Java the the input from the remote system is in the windows encoding?
I have tried the following:
_receive = new BufferedReader(new InputStreamReader(_socket.getInputStream(),"ISO-8859-1"));
_System.out.println(_receive.readLine());
The extra characters appear as squares in the output with 4 numbers in the square.
Unless you KNOW what the "default encoding" is, you can't tell what it is. The "default encoding" is generally the system-global codepage, which can be different on different systems.
You should really try to make people use an encoding that both sides agree on; nowadays, this should almost always be UTF-16 or UTF-8.
Btw, if you are sending one character on the Windows box, and you receive multiple "strange symbols" on the Java box, there's a good chance that the Windows box is already sending UTF-8.
Use cp1252 instead of ISO-8859-1, as it is default on windows.
We have an application which is talking with Flash clients through sockets. The messages are in XML and not too long, up to 1000 chars.
After the update the messages aren't received correctly at the client side - one byte is missing at the end. The first message is correct, the byte is missing from the end of the second message and the Flash stops because of the parse error.
The application is running on Linux in the production, but I was able to replicate the error in my development environment in Windows.
There are two classes used for the communication:
WrappedInputStream
and
WrappedOutputStream
I can modify the Java source, but I'm not able to modify the Flash client.
Has anyone else experienced a similar issue after the Java update? Is there a way how to fix it?
I would write some unit tests where you are using a ByteArrayInputStream and a ByteArrayOutputStream and/or PipedInputStream + PipedOutputStream and try to simulate the problem.
i.e. if this really is a Java problem, you should be able to write a self contained test which fails (based on what you have seen fail with flash)
You could try to make sure that the WrappedOutputStream is being closed properly. Since the purpose of this stream is to send some data without closing the parent stream, there may have been some misunderstanding on the part of the developer, so the stream did not get closed.
Ultimately I would like to use a Java program to send and receive messages from a phone that I have plugged in via USB. I can do this using a C# program, however the program I want to send and receive messages is written in Java. To do this I am using the Rxtx library (but using the Windows x64 compiled version from Cloudhopper). But whenever I try and send any commands to the phone via USB my computer completely locks up and I have to hard-restart it.
The code I am running is here: Two way communication with the serial port. I think that it successfully establishes a link since it gets to the stage where it accepts input from the console, though when I press enter, and the input is sent, the computer locks up.
I am running Windows 7 x64, using Eclipse. Thank you for any help.
A little hard to tell from the code, but here are some debugging tips:
Try stepping through the code with the debugger line by line, and step in to the library itself to see if you can find the problem.
Instead of reading/writing from the console, try sending character codes programmatically. The console operates very differently from direct access. i.e. instead of System.in.read()) just try passing in a known good String.
Keep in mind that Java works with UCS-16 internally, but that consoles typically work with different character encodings (e.g. cp1252 for Windows). So, your "enter" may be a completely different character from what the system is expecting. If your device is expecting ASCII 13 and your keyboard is generating ASCII 12, that could be enough to confuse things.
The crash makes it seem very likely that there is something going on with the native library. If you find that the Java debugging keeps dropping you into the JNI boundary, you may need to debug with a C/C++ toolset.
Good luck!