Charmed Quark Systems, Ltd. - Support Forums and Community

I am in the process of developing my iPhone RIVA client. I have managed to get far enough to log in successfully, which is good. Some notes and questions:

I'm glad that I took my friend Rob's suggestion to look at the .Net RIVA code after banging my head against the wall trying to figure out how to get the Blowfish code working. I see in your code that you are converting your 16-byte blocks into 4-byte chunks using big-endian encoding. I hadn't anticipated that. When I switched to do likewise, it magically started working. Is there a reason why you do it that way? It would be good to make a note in the documentation, for the benefit of future generations of RIVA developers.

It appears that you are using four-byte lengths for the strings that appear after the message structure. The header file reflects this. But the documentation states that the lengths are stored in two bytes. That should be corrected.

On the same subject, I would have thought from the documentation that only messages containing a text string would have the length bytes and string at the end. But, looking at what the server is sending as a LoginChallenge, I see that the payload includes four extra bytes, which I presume are a string length, even though there's no string in a LoginChallenge. Is it the case, then, that all messages include a length, which is set to 0 if there's no string? Should I likewise always include a length in my messages, and set it to 0 if unused?

How does the TException message look? Does it have seven length-and-string pairs, or does it actually have an eighth length at the end set to 0, like a null termination? Is there a way to get the server to generate a TException, so I can test my code?

On a purely cosmetic level, while I was playing around trying to figure out the length byte thing, I deliberately sent a Ping message first, instead of a LoginRequest, to see what would happen. The server logged an error saying that it received a LoginRequest opcode when it was expecting a Ping opcode (the reverse of what actually happened).

Thanks.

The login challenge can include an error message if the request fails. Only those structures that include text will have those extra bits at the end, but in some cases the string is empty, in which case you have an empty length. So if the c1Error field of the login challenge is set, there's a string at the end with the error message, else it's the empty one.

The exception is indeed a set of length/text pairs at the end. So it will generally require a special decoding method, where's almost everything else has no text or one piece of text and can be handled by a single method.

On the Blowfish blocks, Blowfish implementations assume big endian format, so on little endian platforms, you have to flip them before processing.

I'll take care of those errata in the docs, thanks for pointing them out.

Basic drawing is now functional on the iPhone. I have a question about the clipping modes. Apple's drawing environment basically supports only AND mode, where the new clipping area is intersected with the existing one. To open up the clipping area, you have to pop the graphics state. So to support RIVA's various modes, I will have to manage the clipping areas using my own internal stack, apply the current clipping area when called for, and pop it off when the operation is done. I can certainly do that if I have to.

But I have noticed that the commands sent out by the server only use the COPY mode when there's no existing clipping area, and the AND mode otherwise, which means that my code works just fine by ignoring the mode entirely (the graphics state starts with a default clipping area of the entire window, so COPY and AND are the same thing when starting out). Does the server ever use other modes, or use the COPY mode to replace an existing clipping path? Or is this future functionality that I can ignore for now, as I am doing with the text mix mode? Thanks.

Curently, yeh, that's the case. It could use the other modes but currently doesn't. So, I'd plan for it, but to get to the first implementation, it won't be necessary. So just architect with the understanding that this could be required later, so that you are prepared.

I have identified what I think may be a problem in CQC. My iPhone RIVA client works fine, buttons get pressed, etc. But when I disconnect, something (at port 13505) goes down in the CQC processplex, and subsequent connection attempts are rejected until the service is restarted.

First off, I think I am currently failing to send a proper LogOff command. I need to sort out my state logic and fix the problem. But even if the CQC problem is triggered by failure to receive a LogOff, I'd think you'd want to fix CQC not to have this vulnerability (if indeed there is one).

We have an instance of the variables driver containing a single string variable, and a template with two buttons that stuff different values into that variable and a text box that displays the variable value. Press one button, see the first string. Press the other button, see the other string replace the first. And so on.

When I disconnect, the log says:

The remote client at endpoint 192.168.1.127:52397 dropped the connection (worker thread 15)

(because I didn't send a LogOff).

If I have not pressed either of the buttons, all is well. I can reconnect and see the template again. But if I have pressed one of the buttons, then when I try to reconnect I get this error in the log:

An exception occurred in worker thread 9

and my connection fails. Subsequent connections fail with the generation of the following pair of errors:

The server at 192.168.1.137:13505 was not available
An exception occurred in worker thread 9

It looks to me like maybe the variables driver, or some component like that, is dying. It's always port 13505 that is mentioned as being unavailable. Maybe you will just know immediately what part of CQC that is.

When I restart the CQC service from the control panel, things return to normal, and I can once again connect and see the template, until the next time I disconnect after having pressed a button, at which point the problem happens again.

Let me know if you need any more information about this. Thanks.

Brian

That's the data server. That's something that will be running on the master server and will be called CQCDataSrv, so check the master server and see if that's running. I'm sure it will be, so there has to be something else going on.

I just talked to Sergio and he is having a similar problem. I asked him to get the system into the failed state and run a CQCNetTest and send it in to us. Apparently it happened quite a few times yesterday.

It happens repeatably for me too

Instead of restarting teh service, kill the CQCRemVSrv program. It'll be restarted automatically. If it comes back up, then it's clearly something specific to that remote viewer server.

But it's strange that the other clients aren't seeing this program. Something odd has to be going on there that's specific to this client, but what it is I'm kind of at a loss to say. I guess we could try just killing the .Net or C++ client via the task list to simulate a non-graceful shutdown and see if that replicates the issue.

Dean Roddey Wrote:Instead of restarting teh service, kill the CQCRemVSrv program. It'll be restarted automatically. If it comes back up, then it's clearly something specific to that remote viewer server.

But it's strange that the other clients aren't seeing this program. Something odd has to be going on there that's specific to this client, but what it is I'm kind of at a loss to say. I guess we could try just killing the .Net or C++ client via the task list to simulate a non-graceful shutdown and see if that replicates the issue.

I have some random issues that seem to involve the data server.

Every few days, I find the IV locked up and have to reboot the machine. I don't know what triggers it, but in the logs I always find something about not being able to contact the data server.