[Verse-dev] verse-server bugs and problems

[Emil Brink]

On Thu, 12 Aug 2004, Thorsten Jordan wrote:

> Hi!
>
> I have noticed odd behaviour of the verse server in two different ways:
>
> 1) the client should send verse_send_node_create with a node_id of 0
> (zero), wait for the server to send this callback and get the real
> node_id from there, right? Well, the server just doesn't do so. Instead
> it locks up. When I use verse_send_node_create with my own numbers
> (always incrementing the node_id when creating a node) then it works,
> sending any number twice with create causes the server to crash/lockup.

As I explained in my other message yesterday, this is due to event
compression. Your follow-up indicated you understand the issue now,
so hopefully we can leave it for the moment.

> 2) When sending large amount of data, and i mean more than 300 faces,
> the udp buffer seems to overflow or anything similar. E.g. when
> receiving a verse_send_node_create for a geometry node or an
> verse_send_b_layer_create for an bitmap layer I start to send vertex
> data or bitmap data. If i do an verse_callback_update(50000) every 100
> send vertices/tiles or so, the server seems to handle the data (although
> transmission is slowed down obviously), but sending more than roughly
> 200 vertices without an update in between seems to lockup the server.
> Same for bitmap tiles or polygon indices.

I have no insights here, I'm afraid. Perhaps Eskil has, he certainly
has worked a lot more with the current server implementation than I
have, plus also having written it might be a benefit.

One question, though: you use the wording "lock up" a lot, does this
mean the server does indeed freeze, i.e. stop responding to e.g.
other clients attempting to connect? If so, that is a "pure" bug and
it would be interesting to learn where in the code it is sitting when
this happens.

> It also seems that sending server output to an file or /dev/null instead
> of printing it to the console helps a bit against the lockups. Maybe
> this is some sort of timing problem.

Could be simple network starvation, I'm not at all sure how sensitive
it is to such problems.

> (I am using Debian/unstable on i386 - the client runs also on Windows2k
> and WindowsCE, it is the same everywhere)
>
> It is very annoying to work with this server, as it took me a long time
> to detect these errors. I thought the server would be complete.
> Especially the node_id bug is a bad surprise.

You mean the over-ambitious event compression? It has been documented
in the spec for a while, but probably not long enough. Sorry for the
inconvenience.

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

Heh.

> 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:
>
> 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.

Well... I'd say you can't, since vertex IDs are assigned by the host
and not by the client. Also, any dependency on the order of things
should be avoided, since Verse cannot guarantee that commands sent
are processed in the order they are sent; the underlying UDP network
protocol is (by design) too "weak" to preserve such order anyway.

Regards,

/Emil