MXP 0.6 Drafting

[Tommi Laukkanen]

Hello

MXP 0.6 drafting work has started:

http://www.bubblecloud.org/wiki/-/wiki/Main/MXP%200.6%20Scratch%20Pad

Anyone interested in shaping MXP to right direction please take a look
at our scratch pad items. You can either post comments to this thread,
mxp discussion group or directly to wiki.

-tommi

[Alon Zakai]

1. Maybe I am not understanding something, but if all movement is done by request/response, that seems to mandate the Second Life model of all movement/physics/etc. occurring on the server. If so, that would rule out any hi-speed worlds (FPS games, etc.). (In fact any fixed movement/orientation message format would be an issue.)

2. "ENET can have maximum 255 channels. This would enforce ordered dependency for unguaranteed packages. ENET drops out of order (late) arriving unguaranteed packet inside a channel. That is problematic if all movement messages use same channel: Movement messages for different objects arrive in wrong order and late arriving would be dropped. This should only happen if movement messages for same object arrive in wrong order."

I don't follow. First, the concepts of ordered and guaranteed are orthogonal - it is possible to have both guaranteed and unguaranteed messages in the same channel in ENet - reliability is a property of a message, not a channel, and all channels are ordered there.

Generally speaking the worst case scenario with dropped packets here is not a problem - if you send reasonable amounts of movement updates/second for each entity, the chance of all of them getting wiped out for one entity due to ordering is negligible. In practice as well, this works fine with all movement updates in the same channel (for all objects).

(What does *not* work well in practice is to mix movement updates with large amounts of reliable messages - but the problem is primarily *latency*, not dropped packets.)

4. "My feeling is currently that ENET might require too many compromises. All though it would provide robust alternative in short term I am confident that we can create equal quality in our own transport layer with tailored features."

Of course that is possible, but I suspect you will simply end up re-implementing basically the same feature set, and it will take time and effort to debug.

5. Regarding the 'persistent flag' - I also think that is a good idea.

- kripken

[Tommi Laukkanen]

Hi

Thank you for continuing to work with us on betterment of MXP
specification.

On Nov 11, 10:22 am, Alon Zakai <a...@syntensity.com> wrote:
> 1. Maybe I am not understanding something, but if all movement is done by
> request/response, that seems to mandate the Second Life model of all
> movement/physics/etc. occurring on the server. If so, that would rule out
> any hi-speed worlds (FPS games, etc.). (In fact any fixed
> movement/orientation message format would be an issue.)

You are right it would induce considerable delay and it may not be
feasible at all.

>
> 2. "ENET can have maximum 255 channels. This would enforce ordered
> dependency for unguaranteed packages. ENET drops out of order (late)
> arriving unguaranteed packet inside a channel. That is problematic if all
> movement messages use same channel: Movement messages for different objects
> arrive in wrong order and late arriving would be dropped. This should only
> happen if movement messages for same object arrive in wrong order."
>
> I don't follow. First, the concepts of ordered and guaranteed are orthogonal
> - it is possible to have both guaranteed and unguaranteed messages in the
> same channel in ENet - reliability is a property of a message, not a
> channel, and all channels are ordered there.
>

The problem I am worried about is that order changes between movement
events of different objects will lead to packet drops. I don't know
the statistics but I would assume that over network connection
containing multiple hops you will get UDP packet order changes as UDP
does not guarantee ordered delivery. If there are considerable changes
in order this will lead to considerable packet loss. This will in turn
degrade the signal quality and degrade the user experience. Does
anyone have reliable measurements on the amount of udp packet order
changes in packet stream for example between continents?

>
> Of course that is possible, but I suspect you will simply end up
> re-implementing basically the same feature set, and it will take time and
> effort to debug.
>

One major pro ENET thing would be appearance of public specification
which could be added as part to other specifications like MXP. It
would also allow evaluation of the protocol and implementations in
different languages.

Dealing with wrappers is doable and it would offer 100% compliant
implementations as everyone would be using the same c++
implementation. The challenging is to make those wrappers happen and
arranging prebuild distributions of ENET libs to all the platforms and
bundling those with MXP. Leaving the building of native libraries to
end product developer is a killer especially when library like MXP is
in question.

regards,
Tommi

[Alon Zakai]

Packet drops occur, but in practice are generally not an issue in this particular issue. One reason is that order is maintained between messages, and multiple messages are combined into a single 'big' UDP packet (by default 1400 bytes in ENet, IIRC). Within each such UDP packet the order is maintained. While UDP packets may be reordered, it is rarer than what would have been the case if each message had a chance to be reordered. In fact it is often the case that all the movement updates for a server frame fit in *one* UDP packet, so there is significant time delay between UDP packets.

Furthermore, movement/position updates are sent constantly, in order to reduce latency. So if you miss some due to ordering, that is regrettable, but not catastrophic (you will get the information very soon after).

(If your priority is signal quality and not latency, then of course a completely different protocol might make sense.)

In any case, the limit of 255 channels in ENet is trivial to extend to however many you want, so one channel per entity would be possible. If it were worthwhile it would probably already have been done, though.

 

Does
anyone have reliable measurements on the amount of udp packet order
changes in packet stream for example between continents?

I can't think of a good source for that, sorry. Would be interesting to know, though.

But some real-world applications using ENet are used all the time across continents, and movement updates work fine.
 
- kripken