Official RIVA thread

[Fonceur]

Actually sending the request to 13516 doesn't make sense, as you need to include the cookie, which you wouldn't need for 13516 since you are already authorized...

[Dean Roddey]

Yeh, you send it to the other port. Are you sure you are reading back from the other port for the reply?

[Fonceur]

Are you sure you are reading back from the other port for the reply?

Yes, using wireshark, it's not seeing any replies to my query, not even an error message or such... Here's what I am sending:

Header: [Unsigned Byte: 2e, Unsigned Short: 1, Unsigned Short: 40, Unsigned Byte: 82, Unsigned Byte: f1]

Body: [Unsigned Byte: 0, 0 85 231 226 3 115 248 12 17 179 67 157 23 158 0 14, Unsigned Integer: 1, Unsigned Integer: 27, UTF8 String: CQCRepo::\System\LEDs\Glass\Small\Green]

Which wireshark sees correctly as being sent by the app (to port 13517) as:

2e 01 00 40 00 82 f1 00 00 55 e7 e2 03 73 f8 0c
11 b3 43 9d 17 9e 00 0e 01 00 00 00 27 00 00 00
43 51 43 52 65 70 6f 3a 3a 5c 53 79 73 74 65 6d
5c 4c 45 44 73 5c 47 6c 61 73 73 5c 53 6d 61 6c
6c 5c 47 72 65 65 6e

[Dean Roddey]

Doesn't the flag field come before the session cookie? Maybe I'm misreading that, but it looks like you are sending the session cookie then the flag?

[Fonceur]

Doesn't the flag field come before the session cookie? Maybe I'm misreading that, but it looks like you are sending the session cookie then the flag?

The single 0 for the flag is before the cookie (0 85...).

Code:

0, 0 85 231 226 3 115 248 12 17 179 67 157 23 158 0 14

I guess I'll have to wait on batwater to come back from vacation to know what the CQC logs have to say about it...

[Dean Roddey]

What's this guy for:

Unsigned Integer: 1

There's nothing after the cookie but the string length and the string.

[Fonceur]

What's this guy for:

Unsigned Integer: 1

There's nothing after the cookie but the string length and the string.

Oh, that might be why... From the documentation:

When the client connects to the image server, it will send a TReqImgDownload (...) This will tell the server what image is desired. You will just pass back in the image path and serial number that you received in the drawing command.

That's why I hate things not being spelled out in the structure...

[Fonceur]

OK, that was it, there should not be the serial number of the image in the message.

[Dean Roddey]

Yeh, you get the serial number. So you would only ask if you know that you were asked to draw something that you didn't already have. You get the current serial number back, to store in your cache when you put this new image in it (or replace the existing one in it.)

There's nothing passed that's not in the structure other than the text stuff, so if you see anything in the docs that claims otherwise, let me know. I'll change that one.

[Fonceur]

send a ping to keep the connection alive. It's just an opcode so it uses the TGenOpCode structure.

Is it the same thing as the ACK, to keep receiving more than 200 messages, i.e. header with no load at all. Or is the load supposed to be the unsigned integer for the length of the non existing text, which is not following it? Same thing for the LogOff and other "just an opcode, but not really" messages?