[Verse-dev] [Verse-dev]understanding event collapse

[Marcus Hoffmann]

> The basis of this system is that UDP network packets can arrive out of
> order. or get lost (if a packet gets lost it will be resent and hence
> out of order, so in this mail i will only refer to this as out of order.)
>
> if we now consider us sending thees 2 commands:
>
> verse_send_g_layer_create
> verse_send_b_init_dimensions
>
> if thees two commands arrive out of order it doesnt matter because the
> deal with two different parts of the data set that can be updated
> independently.
>
> However, what if the two commands are the same commands? lets imagine
> that we send the following two commands:
>
> verse_send_b_init_dimensions(1, 128, 128, 1);
> verse_send_b_init_dimensions(2, 256, 256, 1);
>
> if thees two commands arrive out of order it doesnt matter either
> because even if they use the same command they deal with two different
> nodes. The problem comes when you have two commands that deals with the
> same data:
>
> verse_send_b_init_dimensions(2, 128, 128, 1);
> verse_send_b_init_dimensions(2, 256, 256, 1);
>
> Now this would be parsed as the bitmap should have a size of 128*128*1
> and then it is changed to 256*256*1. If the two arrive out of order
> there will be a problem, because the node will first be 256*256*1 and
> then 128*128*1. In other word we would get the wrong result and the two
> sides would be out of sync.

So this is another good example where a change command would be a benefit.
If you send the first create command and after that a change command may
looking like that:

verse_send_b_init_dimensions(2, 128, 128, 1);
verse_send_b_change_dimensions(2, 256, 256, 1);

you would have no problems with overwriting something. If the change command
arrives before the create command nothing will happen! and then the create
command arrives and will create a layer.
Yes - the change is lost, but you won't have wrong data. But what you then
can think of is a stack that holds the change command for a short time. and
looks for an arriving create command that contains the layer or node that
you wish to change......

But its in my eyes a clearer solution and much easier to implement and to
understand.
The Problem with the out-of-order-incoming-commands will be a problem
anyway, no question, but catching those events is much easier in the way i
thought of.


> The basis of this system is that UDP network packets can arrive out of
> order. or get lost (if a packet gets lost it will be resent and hence
> out of order, so in this mail i will only refer to this as out of order.)

This "or get lost" is a really scaring thing. maybe in most cases it doesn't
matter, but for compression its really a hard thing. If i loose vertices or
a structure information, every compression algorithm will crash. if you want
to compress a mesh with holes (because vertices are lost) or a polygon that
references to non-existing vertices because they were lost, i will have a
big problem... And the thing is: If the compression crashes, every
application that uses a compressed geometry will maybe have a crash too.

A really new thing here - and different from the above discussed problems -
is that i would like to have any information about a mesh. verse does give
me a polygon structure, but no information what is a mesh and where another
one begins. This is really immportant for good compression. Is there
something included that i've not found? Or do we make the internal (or in
the spec) agreement, that every geometry node is one mesh, or every polygon
layer describes one?
And if we do so, really everyone should follow this order. Because i would
then implement the compression on the server relying on that.