[Verse-dev] verse-server bugs and problems

[Eskil Steenberg]

Hi

> Please focus your work on things that matter, like these, and not wether
> node_ids start at 0 or 1. ;-)

I will ;-)

The lock up is something i have not experienced that i know of. But i 
will look in to it. Emil could you do the same? please you are running 
linux.

The not so great performance is a known problem. I was planing to take a 
crack at it in about two weeks. Right now it works but is not optimal, 
so you should be able to survive. Optimizing UDP turns out to be a bit 
of black magic but i will get to work on it.

> Ah, another thing: the server seems to reverse the order of commands he
> receives. Sending layers 1,2,3 from a client leads to an retrieval of 
> 3,2,1 (very often) at the same client. This is not really a bug, but 
> keeping the order would be great for many reasons:

I know... this is actually meant to be annoying....

Verse has a very special network system that removes the need to have 
network packets deliver in the right order. this is especially important 
when packets are lost, because no data has to wait for a lost packet to 
be re-sent. So no properly written app should not require stuff to be 
delivered in order. Hence the huge id debate on why strange things 
happen when things are out of order (Ha! it DID turn out to matter! ;-)).

Verse used to send everything in the right order but, due to some things 
taking up very much cpu I rewrote some stuff that caused the commands to 
come in a different order even if the network delivers all packets in order.

At first this annoyed me too. But it did not brake any of my apps 
because i was aware of this when i wrote them. But it did turn out to 
break other peoples apps because they where not aware of the out of 
order problem. So this made everyone aware of the issue and this is why 
we have all this email traffic to fix it (and thats a good thing). If 
verse would not have reordered it the network might have and the bug 
would still be there but it would be a lot harder to find the bugs 
because they are so rare. In a way verse has become less forgiving in 
that sense.

If you want to you can change the define in v_network_que.c:

#define V_NQ_OPTIMIZATION_SLOTS    4096

to

#define V_NQ_OPTIMIZATION_SLOTS    1

to get it to work like it used to. But then again it will be slower and 
any bugs you are experiencing now will still be in you code just show up 
more rarely.

> the clients could create layers/vertices/indices in a sane order, 
> creating nodes/layers before referencing it, or creating vertices 
> before creating face indices that reference the (not yet existing) 
> vertices. The client could then e.g. create vertex n first and then 
> vertices 0...n-1, so that an array resize can be done only once and 
> not n times on another client who receives the vertices. 

vertices and polygons are numbered by you and not the server. so you are 
allowed to create polygons that reference vertices that doesnt exist. it 
will not be a legal polygon to draw but to store . (just like you can 
delete a vertex used by a polygon without deleting the polygon)

When you send vertices(or polygon) you are expected to create them 
roughly from zero and up. Creating a vertex with a id substantially 
higher the the highest existing one may be declined by the host. (since 
people are expected to allocate memory in arrays it would be an exploit 
to create a vertex with a so high id it would require clients to 
allocate too much memory)

when I allocate/reallocate i always allocate a bit too much (see Enough 
source) this helps against too many reallocations.

Cheers

E