Charmed Quark Systems, Ltd. - Support Forums and Community
.Net RIVA Client - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forums)
+-- Forum: Third Party Development (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=8)
+--- Forum: Third Party Development (General) (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=22)
+--- Thread: .Net RIVA Client (/showthread.php?tid=5673)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


.Net RIVA Client - bryanb - 06-16-2009

Mark,

I think that has made a difference. I started it a couple of minutes ago. I'll check again when I finish this post.

When I installed the 1.2B1 CF client in the iPaq, at first it would not connect. Said error in login stuff. I double checked the config file and everything looked fine. So I remembered that this has happen to me before during the last few days. All I did was cycle the CQC service on the MS and the RIVA client then connected and logged in successfully. This has happen to me before 1.2B1, so it's not just this version. I'm on CQC .53.

OK, the client has been running for about 10 minutes now and no reconnects.

Thanks for the help,

Bryan


.Net RIVA Client - bryanb - 06-16-2009

Mark,

The client just reconnected. CQC log said "Idle time exceeded". It did reconnect. Is this normal procedure? Do you not want the client to stay connected all the time? What's the purpose of dropping the connection after an Idle Time, if you're just going to reconnect automatically.

Bryan


.Net RIVA Client - bryanb - 06-16-2009

OK, just had another reconnect. Something about payload not large enough.

CQC log file is attached.


.Net RIVA Client - Dean Roddey - 06-16-2009

The reason for the server to have an idle time disconnect is that there's not supposed to be any idle time. If it doesn't see anything from a client within a minute, it assumes the client has croaked or something has gone wrong and it drops the connection. Otherwise the server would end up with lots of dead connections.

So something prevented the client from talking to the server for too long. It didn't have to be a minute. The client probably checks and, if nothing has been sent to the server in the last 45 seconds, it sends a 'keep alive ping' to let the server know it's still there, just not doing anything.

So if something prevented it from talking for long enough that that ping didn't get there within a minute, that would cause the server to drop it.

We could possibly make it a bit longer, but I'm not sure it makes any difference. If the client can't send the ping, it can't send anything else either, so the user can't really interact with it if that's the problem anyway.

The RIVA clients are designed to just try to reconnect if any network slowness causes the connection to be dropped or any loss of packets between them, so that they have more survivability of iffy connections.

Now, whether that's the problem, I don't know. It's always possible Mark still has some slight goober in the ping logic or something. But a flakey network connection can cause that disconnect/reconnect to happen.


.Net RIVA Client - Dean Roddey - 06-16-2009

bryanb Wrote:OK, just had another reconnect. Something about payload not large enough.

CQC log file is attached.

You forgot to attach the log. But that's likely a spotty network connection, so that all of the contents of message couldn't be delivered in a reasonable time, with a simple mode client that would be an image almost certainly.


.Net RIVA Client - bryanb - 06-16-2009

the log is attached to post #83.


.Net RIVA Client - Mark Stega - 06-17-2009

I agree with Dean, this looks like a network glitch. It isn't regular like the last issue. I am chasing one other disconnect issue so hang on and let me see if it might be related.


.Net RIVA Client - bryanb - 06-17-2009

OK, it maybe a network problem. I'm just trying to tell y'all what I'm seeing. Through the night, the CF client reconnected about 8 times. According to the CQC log, 2 of them were because of the "Exceeded Idle Time" error and 6 were the "Payload too large for access type" error. Are you saying that you think all of these were network glitches?

I'll fire up the 1.2B1 version of the FF client on the Q1 and see if it experiences the same problems. There both still on the same access point.

Thanks for the help.


.Net RIVA Client - Mark Stega - 06-17-2009

bryanb Wrote:OK, it maybe a network problem. I'm just trying to tell y'all what I'm seeing. Through the night, the CF client reconnected about 8 times. According to the CQC log, 2 of them were because of the "Exceeded Idle Time" error and 6 were the "Payload too large for access type" error. Are you saying that you think all of these were network glitches?

I'll fire up the 1.2B1 version of the FF client on the Q1 and see if it experiences the same problems. There both still on the same access point.

Thanks for the help.
The 'exceeded idle time' is almost certainly a network glitch. I am exploring the 'Payload too large' issue.


.Net RIVA Client - Mark Stega - 06-17-2009

The 'payload item' issue is fixed. I'll post a new viewer in a bit.