1. The loss is quite high, about 17% are lost (without increased viewrange: max. 0,8% over the internet!)
   
2. I´m running server and client on the same machine, how can this loss be caused?!
   

So, do you have any idea how those UDP-Packets can be lost?[/quote]

Wrong question.

UDP packets are unreliable. They may be more reliable or less reliable, but they may get lost, regardless of the path they take.

They might get lost on the sending side, trying to send too much and kernel discards them. They might get lost in kernel, where anti-virus suddenly decides to preempt some thread and kernel does something funny.

They could get lost in packet storm, such as application sending >64kb of data in less than a timeslice allocated to it.

This, for example: 'socket.setSoTimeout(1);'

Application waits for 1 millisecond, but nothing arrives so application continues with the loop. But the very next CPU cycle, socket receives 64kb of data, which is done locally, so it's at DRAM speed. It takes ~0.064ms to send this data, during which the receiver will not clear the buffer, so 14kb of data will get discarded.

One way is to set the reading loop to short enough for such events to not occur. Buffer should ideally be large enough to be able to store all data that arrives at least during one time-slice or ~20ms. It's far from a guarantee, receiver thread could be sleeping for longer than that. If sending data locally through DRAM (~1GB/sec), buffer would need to be 20 megabytes large, which simply cannot be done.

But it doesn't matter.

UDP loses packets. You either compensate for that or not. Any case where all arrive or they arrive in order or similar are just luck.

second: you´re not an optimist, right? : P

second: you´re not an optimist, right? : P[/quote]

UDP can lose packets.

Now it's up to you to decide what to do about it.

Current code doesn't do anything, it is simply dumbfounded. That is one way to solve a problem.

Alternatives involve recovering missing packets. There are different strategies, each with strengths and weaknesses.

In all of the above cases, there will come the moment of truth: Does the method used provide sufficient amount of packets for the rest of application to work.

If yes, the approach is sound. If no, another approach must be chosen.

Current approach, considering high packet loss is a problem, is not sound. Solution to this problem is to incorporate a recovery scheme. Perhaps make packets bigger by adding redundancy information from previous and later data. Perhaps attempt to resend the data. Or, layer a protocol on top of it that conveys more information about which packets get lost and how to compensate for that.

The thing is that I thougt that such great jumps in packet loss could have some very clear reason; something like a beginners mistake.[/quote]

Possible. But UDP still won't provide any guarantees. So even if implementation were perfect (proven via some math stuff), unicorns might go on a strike over 1% fairy bonuses and suddenly no packets would arrive anymore.

Basic premise of assuming that UDP will deliver a message is flawed. So regardless of how good or bad the code is, it's just a gambling game with no guaranteed returns.