Apparently there is a difference with socket handling between Java 1.6 and Java 1.7 but its indeed not a bug.You've provided no evidence for either claim. All you've provided and told us about is some very poor quality code that has finally failed due to a major error that had always been there and that could have failed any time TCP decided to deliver the data differently. You should be counting your blessings that it ever worked at all.
957483 wrote:Maybe you should now take another look at the problem that required you to break the data into 512 byte chunks. Maybe you would now find that it was not necessary!
Yes I do control all the code, I had a look at this earlier and discovered that the send and receive code was actually different from the other code. I have corrected this and the system works now.
957483 wrote:My last words on this - to quote your original post
It might be indeed an idea to try but I believe there was a reason for being like that and it had something to do with remote locations and bad gprs cover. Anyways, I'm going to try when I have found a remote spot with bad cover here. I think the 0s were 0x00s which I mis-interpreted after staring myself blind on this.
Code has a reason for its existenceBroken code has no reason to exist. You've already posted one sample, and you've alluded to the existence of another.
I've tried Data(Input/Output)Streams, Buffered(Reader/Writer) in the past and they could not provide the stability needed.So your code was at fault, see above (passim),a nd also your investigative procedures. I've been using all of those for over fifteen years, and I have never noticed a 'stability' problem.
It was until I broke up the stream into smaller chunks when it became stable, something which it has been for three years afterwards.This only goes to prove my assertion. I have been using chunk sizes of 8192 or more over TCP for over twenty years without problems, whether 'stabililty' or otherwise.
This solution worked perfectNo it didn't. Otherwise you wouldn't be posting here. You've already admitted one major bug; I have already shown you a way to reduce 26 lines of spaghetti to 4 lines of correct code; and DrClap has done the same for 30 other lines of 'perfect' code. Your evidence for any of these propositions is badly lacking.
and I had to meet my deadline for this particular project so I moved on to other pressing matters.In other words you didn't test properly, and you allowed flawed code that you didn't completely understand to go into production. If there was nothing wrong with the code you wouldn't be making these excuses and indeed you wouldn't be posting here at all. QED.
The examples provided might not have been of good quality but that is what you get after trying to pinpoint the problem.Unless you are actually asserting that for some reason you made the code worse while trying to fix it, this is meaningless.
Let me be clear, this code/system has been working fine for three years straight, there has never been reported any problem on this subject.Let me be clear in turn. It has been wrong for three years straight. Any change from a new NIC, to an equipment change in an ISP rack, to an operating system upgrade, to a C library change, to a Java version change, could have broken it, and finally one of those did. The miracle is that it ever worked at all. You were lucky, simple as that.
957483 wrote:I thought I had nothing more to say in this thread but I can't let this pass. Once again, one deduces from the sample output you gave that the corruption occurred BEFORE the Base64 encoding and not after you sent the encoded data to the relay or even when sending the encoded data to the relay !!!!!!!!!!!!!!!!!.
sabre150: The zeroes were apparently copied due to the relay in between happily copied over buffers with the wrong number of bytes.
957483 wrote:Which of us is missing the point! IF, AS YOU HAVE SHOWN TWICE NOW, YOUR CORRUPTION WAS ASCII '0' BYTES THEN THE CORRUPTION TOOK PLACE PRIOR TO THE BASE64 ENCODING AND not not not , AS YOU KEEP ASSERTING, AFTER BASE64 ENCODING.
I'm glad i'm keeping your minds occupied.
When I wrote the question I wanted to save you guys from having to read lots and lots of bytes on the forum:
AFSDFSFADASFFCSDS <-- packet to send
A000000000000000 <-- packet fragment 1
FSDFSFADASFFCSDS <-- packet fragment 2
I also did not expect that it would generate so much comments.
I'll be more specific next time, it makes the picture more clear.