Official RIVA thread

[wuench]

That seems to have fixed it. There are still times the buttons don't highlight if you press things too fast, but if you allow about a second between press/release (over wifi) it seems to be working more consistently and consistent with the way the Windows RIVA client works over wifi.

[SamVimes2]

Dean, is there somewhere I can download the latest RIVA header file with the definitions used by the progress bar command?

Hey Dean, where can Brian get the latest RIVA header file (specifically with info about the progress bar)

Thanks!

[brianmount]

Dean, What are the values used in the c1Dir field in the progress bar RIVA message? We found the other information.

[Fonceur]

The progress bar info has been in the RemoteViewerProtocol_3_4.pdf for over 5 months, no?

[Dean Roddey]

Hmmm... I seem to have not ever defined the values for the direction. Oops. I'll update the header, but in the meantime they would be:

Code:

const tCIDLib::TCard1 c1Dir_Left            = 0;
const tCIDLib::TCard1 c1Dir_Right           = 1;
const tCIDLib::TCard1 c1Dir_Up              = 2;
const tCIDLib::TCard1 c1Dir_Down            = 3;

[wuench]

Hmmm... I seem to have not ever defined the values for the direction. Oops. I'll update the header, but in the meantime they would be:

Code:

const tCIDLib::TCard1 c1Dir_Left            = 0;
const tCIDLib::TCard1 c1Dir_Right           = 1;
const tCIDLib::TCard1 c1Dir_Up              = 2;
const tCIDLib::TCard1 c1Dir_Down            = 3;

BTW, you might consider putting that header info into the RIVA doc as an appendix or something. When I was trying to decode those sniffer traces, I was having a hard time figuring out what was what. I finally found the forum post for the header info....

[Dean Roddey]

Yeh, that's true.

[Dean Roddey]

OK, the new additions to allow you to send over environmental variable runtime values is in place in 3.4.11 that was just posted. Here are the changes for the protocol version 3.

Code:

namespace kCQCRemVComm
{
    // -----------------------------------------------------------------------
    //  There is only one new opcode for V3 clients, which is a new version of
    //  the login response. This one allows the client to send along the values
    //  of the environmentally driven runtime values. If a client reports that
    //  it is a V3 client, it must send this version of the response, not the
    //  original one.
    // -----------------------------------------------------------------------
    const tCIDLib::TCard1 c1OpCode_LoginResponse2   = 105;
};

namespace tCQCRemVComm
{
    // -----------------------------------------------------------------------
    //  c1OpCode_LoginResponse2
    //
    //  This is the same as the original login response, except that there is
    //  now a mask that indicates the optional presence of environmental
    //  variable values after the structure, in the standard text sort of
    //  way. The mask indicates which of them are present, so that extra
    //  bytes aren't required to just send empty values, and most of the time
    //  most of them will be empty.
    //
    //  So bit 0 indicates that Env01 is present, bit 1 indicates that Env02
    //  is present and so on. So, for each of the set bits 0 through 8 in the
    //  environment mask, there should be a string following this structure
    //  with the value of that environmental variable.
    //
    //  If no values are present, the mask is zero and only the basic
    //  structure itself must be sent. If, say, only variable 5 were set by
    //  the user, then the mask would be 0x0010 and there would be one string
    //  following the structure.
    //
    //  The server will go through the mask and for each of the bits, it will
    //  extract a string and store it as that corresponding variable for this
    //  client's session.
    // -----------------------------------------------------------------------
    struct TLoginResponse2
    {
        THeader         hdrInfo;
        tCIDLib::TCard1 ac1Response[16];
        tCIDLib::TCard2 c2EnvMask;
    };
}

Most likely the best strategy for the medium term would be, if there is no environmental variables info to send, just report yourself as a V2 client and send the old login. Else report yourself as a V3 client and send the new login.

[Dean Roddey]

So, I was thinking... if packet utilization is a performance issue, would it help if we created a generic 'multi-packet' message, and the server could packet up, say, up to 8 messages at a time if they are available and the size doesn't go above some reasonable size?

It would be pretty easy to support on both side. On the receiving side in the clients, they'd just split them out and queue up them as they would with singles. I'm already queuing messages and sending them out, so it's easy to see if more than one is available and pack up a set.

I assume some of this is happening anyway, given that I turn on Nagle processing on my side. But I'm not sure if it gets the benefits that we might get if I turned off Nagle and did batching myself, so that they go out faster when there's not enough to fill a whole packet, but we get good batching as well when there is.

[brianmount]

Not knowing much about the low-level details of TCP, I sort of assumed that you could fill up a 1000-byte buffer with multiple small commands and call your socket message send call to shoot them out as one packet, and the client wouldn't see anything different on its end. Is that not the case? If not, then I could see how some improvement was possible.

I still think, though, that the big improvements are to be found on the image server side, given that everyone seems to want templates that show big lists of movies and albums, with the cover art thumbnail. Some way for me to request multiple images would be great. I already know what 10 thumbnail images I need, but I can't request a new image from you until I have completely received the previous one. That is the biggest driver of display slowness.

Also, the image files that templates ask me to draw are almost always many multiples of the size they really need to be. I'm drawing 20-by-20 thumbnails out of 100K images. I realize that the template may also at a later time display the full cover art of the album the user chooses to play, at which point the larger image will be used. But if the user scrolls through 50 thumbnails before choosing one album, I wind up loading 50 100K images when I only needed one 100K image and 50 10K images. And caching 500 100K images starts to chew up too much storage on the device, whereas caching 500 10K images is probably OK.

I envision a scheme where the client can indicate the desired size, and the server will, if the image is more than a certain percent larger, scale the image down before transmission. If you want a 20-by-20 image, and the original is only 40-by-40, you might as well send the whole thing, just in case you need it later. But if the original is 3000-by-3000, the server scales it down to 20-by-20 and sends it, along with an indication of the original size. The client is then responsible for using the scaled-down version as appropriate, and requesting the larger version later if needed. And of course, I envision the client being able to request more than one image in parallel, or at least queue up the request before the previous download is complete.