简体   繁体   中英

DataInput: Bytes lost over TCP

I am sending data via

data.writeInt()

where Data is a DataOutput, which has a socket's output stream.

On the other end I have a socket's InputStream and a DataInput and I read by

data.readInt()

I have confirmed that each write is matched by the appropiate read. Then I used wireshark to look at the packages, everyting is there as it should.

However, I get 1114112, when I send a 17. This is shifted by 2 bytes, so is it possible I loose two bytes somewhere?

I did some experiments with adding flush(), but the problem stayed as it was. Also I have not (yet) managed to write a smaller example which shows the problem (which is why I do not include code here). However, the large example is stable, it happens at the same location every time.

With different data, I get 285212672 right after the 17 (should be a 0). This looks like the last byte of the 17 is read twice.

Any ideas what this might be or suggestions how to debug this?

Alex

I have confirmed that each write is matched by the appropriate read.

Clearly that isn't the case. Recheck. Clearly you are out of sync with the sender. Possibly you are for example using read() where you should be using readFully() .

NB TCP doesn't lose data.

This is shifted by 2 bytes, so is it possible I loose two bytes somewhere?

It is certain: 'somewhere' being in your code.

I did some experiments with adding flush(), but the problem stayed as it was.

Only to be expected. There's no reason why flush() should make any difference.

Also I have not (yet) managed to write a smaller example which shows the problem (which is why I do not include code here). However, the large example is stable, it happens at the same location every time.

Again this is only to be expected. You have an application protocol error.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM