Too much frame data (revisited)

Vine
1

I thought I’d better add this as a new topic so it didn’t get missed, as I think the root cause is a bug in Vine Server :slight_smile:

To better understand why I thought I was getting too much frame data, I tried experimenting with different sizes of capture area and then looked at the captured data as a series of images.

I found that once the size of capture area exceeded a certain threshold the resultant image was becoming corrupted.

For example, a 64x64 pixel area was fine - no corruption. But a 128x64 pixel capture would have image corruption after the 57th/58th scan line. By corruption I mean that the following scan lines are offset by a pixel or two, as if a few extra bytes have been added to the data stream.

As a complete shot in the dark I looked at the Vine Server source and tried increasing the UPDATE_BUF_SIZE macro (in rfb.h) to 100000. And voila, the corruption went away.

I increased the capture area again, so it exceeded the UPDATE_BUF_SIZE buffer once again, and the corruption reappeared.

So it looks to me as though there is a subtle bug in the way the client update buffer is emptied and refilled when it’s too small to hold a complete update. Make the buffer big enough to handle a complete update for the area you want to capture and it’s fine. If it’s too small it seems to create corruption in the data stream.

And if the buffer is big enough to handle a complete update in one pass I get exactly the expected amount of data arriving at my client :slight_smile:

It’s all to easy to cry ‘BUG !’ at the first opportunity, I know, but it would be great if someone at Redstone could look into this and verify my theory.

PS. If I’m correct this should also be evident when using VNC in its normal mode of operation i.e. transferring a video display to a remote terminal. It’s probably masked by the fact that you only get a full update initially. This would be corrupted but you might not see it as subsequent, and rapid, updates would be a lot smaller than the update buffer size (as they are likely to be compressed).

Cheers,
Darren

2

Thanks for the detailed report!

It sounds like maybe the server is squeezing another message in between the blocks or something of that sort. We’ll look into this as soon as we can. In the meantime, I wonder if you would try downloading the latest version of Vine (3.0 was just released last night!) and verify whether you are seeing the same problem. This is happening when you’re running with Raw encoding, correct?

3

Hi,

I’m probably not going to get chance to look at this for a few days…
But, yes, I’m using only raw encoding.

Cheers,
Darren

4

Thanks for the report; it’s very helpful information.

It’s very possible that you are indeed seeing something going awry with the send buffer. We’ll definitely look into it and make a fix if necessary. An important things for us to know as we conduct that investigation.

What are ALL of the encodings you are sending as part of your RFB initialization?

Do you set a Pixel Format when you connect or do you use the server default?

5

I don’t request any encodings or pixel formats - I’m just using the server defaults.

My message handshake is as follows:

Receive protocol version (from server)
Send protocol version (to server) RFB 003.007
Receive security types
Send VNC auth request (if supported)
Receive auth DES challenge
Send auth DES response
Receive auth status
Send request for non-exclusive access
Receive server initialisation message

Send frame buffer update request
Receive frame buffer update
etc.

6

We’ve reviewed this code pretty thoroughly at this point and have done tests with a number of VNC clients all using the raw encoding – everything seems to be working here.

Were you ever able to determine if your client had an issue? Have you tried other VNC servers (we recommend TightVNC as the base that Vine Server is derived from).