Hello
This is a mixed post so I will post it also in Physics forum.
Seems I have encountered a hard and obvious problem while testing a simple game over a P2P net and using JME physics 2 (with ODE impl) .
When a peer generates an event, firstly applies it to himself and then it sends to the other peers connected.
To avoid desync I could multiply message network delay with body force and obtain the same effect on all peers, but this doesn't solve the problem since all the messages arrived after timestep computation should be discarded also on the peer who generated them…
has anyone already faced this?
P.s. note that in a previous post was already discussed the difference between this strategy and the other consisting of broadcasting Physics node state (that sure avoid this problem :|)
JGN does a good job of handling the majority of problems here. First, instead of sending "events", it sends positional and physics synchronization information (Box A is at this location with these forces currently acting upon it) which resolves the issues of events either getting lost or stacking and being out of date.
The next step in JGN that assists with this is the use of RealtimeMessage which is a special message that a message queue will disregard multiple copies of for the same grouping. Essentially what this provides is if Box A is sending updates every 10ms and the machine gets bogged down for two seconds it doesn't send 200 messages (199 of which are now out of date) because every time a new copy of that grouping message is received the old one is disregarded and never sent. The same occurs on the receiving side. If those messages have been received into the processing queue but haven't been processed and applied yet it won't stack up messages (causing that scary game pause that can happen when you're re-enacting several positional changes to get back into sync) it will just disregard all the old ones and only apply the newest because that has all the information it will ever need.
right my pig-headed opinion was referring to dynamic nodes not changing during a timestep thus not requiring constant update in order to save net resources 
Yes, but as I've had to explain before, though your purpose is to make the network work smoother, you in effect make it much worse for yourself. Allow me to explain:
1.) By sending events, yes you only send an event when something changes, but you then have to use reliable traffic (most likely TCP). The problem with this is that TCP is much more prone to lag spiking than UDP because of your guarantee of delivery. In a situation where there is a problem with the network traffic on TCP everything gets missed and your lag that you see is not typically caused by that but the resulting fact that more and more events were created during that spike which caused a bunch of data to be sitting not being sent, so when the connection is back there's so much more data that has to flow through you get a massive delay. If you use UDP on the other the traffic is constant yes, but in case of a network problem even for a few seconds as soon as operation is back to normal so is your game because every UDP message was just dropped in-between and the next received message got you back into sync with the game.
2.) Sending events can also give you serious problems as you have to buffer on some level what is happening or you'll get more messages sent for small events occurring than you would for sending synchronization every few milliseconds. (extra complication on your client)
3.) Sending synchronization (specifically the way JGN does it) removes the complication of networking from the developer. You simply register the object you are synchronizing on both sides (the one who is sending synchronization events and the one receiving) and then you go about life in your game no longer thinking about the networking…the object is being updated automatically and your game doesn't need to worry about it.
4.) If you are concerned about net resources you shouldn't be playing a game via the network. 
Fluid network traffic in a game makes the game look and feel smoother as opposed to events being sent across where sometimes you will be sending LOTS of traffic and others very little.
Sending events in my opinion is bad except where absolutely necessary. I believe it is one of the largest causes to crappy networking experience in games. :o
and crappier than ever when i use events to addforce to dynamic nodes instead of simply translate them
ouch. :-o
I insert here the question posted in in my post.
The realtime message is the response to my question (purge unsent message wich are out of date), so I see SynchronizeMessage, for sync DynamicPhysicsNode, is a realtime message, but it appens to me that the queue reaches max size after a wile sending at interval of 1 second.
The method I use is JGNClient.broadcast, is this compatible with realtime messages ?
You’re also welcome to post at http://forum.captiveimagination.com.
Are you calling update on JGNClient and JGNServer? It sounds like messages are never being processed so eventually it will simply fill the queue.