i do agree that it is not acceptable to needlessly send packets with the framerate of the application. However, the function that is called at each iteration is merely a check if something needs to be synchronised. If none of the synchronised objects change state, the "poll" doesn't waste network/CPU resources (at least not much). Decoupling the "local object update" and serialisation (which would trigger deserialisation at the ghosts) in combination with dead reckoning would be a way to both control/limit the network traffic and having good visual apearance. Seen as such, the "once per frame" activity would be a combination of receiving network updates when available and predicting the new state (position/orientation etc).
For my current application this is not a problem, meaning that i serialise the object position (using a method of the ReplicaManager) as soon it is localy updated. In case of a local player update this is done in the event handling method of the application. In case of CEL, this should be done somewhere in the property classes.
P.S. BTW, do you know that Sun has now released the source for SGS/DarkStar server and client. I downloaded and went through the manuals, but as its all Java-based it does not suit me.
Darkstar is indeed mainly java, and as such looks not suited. Using it from C++ would involve 2 parts that have to be written
1- java part, that is plugged into the (java) server-framework
2- C++ client that uses the C++ library (present in the SGS SDK)
For a CS plugin, these parts would make "part" of the plugin.
The point is that i don't know any C/C++ opensource solution if you want to create robust scalable MMORG applications....
On the speed issue: i think that the network will be the bottleneck and not the (slower than C++) java processing.....