[Verse-dev] Verse r4

Emil Brink emil at obsession.se
Sat Oct 23 17:22:45 CEST 2004


On Sat, 23 Oct 2004 16:27:13 +0200

[missing data]
> > Do you terminate your application immediately once
> > all data is sent,
> > without also subscribing to the layers to keep track of what data has
> > been received by the host?
>
> Brecht suggested doing that. I made a quick fix by not letting the 
> pusher terminate the connection. it just sits forever calling 
> callback_update, so this shouldn't be the problem.

Okay, that's good to know. I built your program (the version found on
the page you linked Brecht to last week, or whenever that was but had
problems finding the test data. Where can I find e.g. the bunny model
as 3ds?

> Brecht said i have to confirm the sent data, quote:
> "What might be going wrong is that the they have are not completely
> received by the server. As far as I can see you are not waiting for
> confirmation that the tiles were received, just for confirmation on the
> layers. The same goes for (large) geometry."
> 
> how do i confirm? subscribe all layers, wait for every tile or layer 
> entry until it is received before quitting the pusher?

Yes, that would be a fairly easy way, since you already have the data
arranged into layers locally, you can subscribe and see that the returned
data matches... I guess this has a slight chance of breaking if someone
starts editing the mesh *during* the upload, since then the situation
where the host-sent data is exactly equal to your buffered data might
never occur.

To work around this, it should be possible to use the function that
tells the size of the to-be-sent (outbound) queue, verse_session_get_size().

Unfortunately, as mentioned (here at the Conference) by Brecht and then
confirmed by Eskil, verse_session_get_size() includes the ACK/NAK
commands, which your application shouldn't need to care about. This
needs to be fixed, so that an application such as yours can simply
loop after sending the data, calling verse_callback_update() and
monitoring the outbound queue. When the queue is, um, very small, it
should be safe to assume it's all sent.

I'll leave it up to Eskil to comment on when this problem can be
fixed. Hopefully before he leaves for Japan. :)

This solution should be far simpler than keeping track and comparing;
so it's really the one I'd would like see working soon...

Regards,

/Emil


More information about the Verse-dev mailing list