I think you should monitor your traffic. If it''s very low, like 0.5 kb/sec, you could resend the packets way more often than 500 ms.. 500 ms sounds kinda high to me, but I suggest you try with different values and try to keep the traffic low enough

In terms of thru-put rate a possible solution is to monitor how big the queue is. If the queue is backing up then you have to decrease the Tx rate, on the other hand if the queue is continually empty then it should be safe to increase the Tx rate.

Currently I am finding that 5 to 10 messages a second are enough for real-time movement. Consider how many bytes are being used for a single absolute update message and how many game charaters/objects are you trying to update. You may need to consider using an absolute/delta message combination.

Avoid sending duplicate packets to keep the bandwidth usage down and you can use extrapolation between points to reduce the number of require messages and smooth out the ghost character.

As for what time-out to use, well, say your using a 200mSec period on your position messages. Is there any point in having your time-out period longer than 200mSecs because if a message is in the queue long enough time-out.

(A) Theres a bigger problem with your queue and thru-put rate
(b) Theres a more up-to-date message about to go into the queue,
(do you still want the old out of date message).

You could maintain a ping signal between client and server, and use latency times to calculate a suitable time-out value.

Say you get a measured latence time of 100mSec, you could use this as a bases for your time-out. Bear in mind the above situation.

Hope this helps.

P.s. Fixed values are not a good idea since network states are transiant. Your time-out should be calculate to suit the current state of the network, ie a Lan would generally have a latency or about 10mSec where as the internet is 100+ mSec.