New Test Release

[MrDoh]

I just did some more basic tests. If you would compile me a version based on this test code version, and just for testing purposes, put a pause in the updating while the mouse is being presses. (please, please, please... and I'll test 2 night)
(But get your sleep etc... I'd rather wait than you get burned out!)
hehe
My thought is, if you do this, I will not have many more lockup problems while zooming.

What is actually making it freeze though? Just because the cpu hits 100% for 2 seconds is no reason to just up and quit, is it?


Hey wait.... maybe the client, or the server needs to decide to throw a way a few packets if it gets over a threshold... Still just poking in the dark here...

There again, are we looking in the right direction? is it maybe the screen trying to redraw or rearange in the middle of something else going on that freezes it. But that something else only happens when connected, because when offline and I load a map I can zoom, and move the map all over, use all the menus, and columns etc, so it is something that only happens while connected.

I will tell you that offline, with a map loaded, *holding* down the zoom button all the way to 10000, and immediately back down to 100, Iand cpu at 100% can do this repetedly without problem. With the same map loaded and connected, the most I have ever gotten to was 250 zoom, and the cpu never even got to 100%.
I even go, then stop, then zoom to 10000 fine.

For what it's worth,
Mr. Doh
As a side note, tell me what you code the client in? I know it's C#, but do you use an interface, do they call it an IDE? (hehe told ya I'm no programmer!) If I get a little more information and get quazi-structured look at the client code, I might could be doing tonights testing and recompiling without wasting your valuable time. Really, thanks again for all this hard work!

[cavemanbob]

I use visual studio .net, which the best IDE that i've had so far.

I've got the code for using big packets done and am just giving it a quick test before posting it. It seems more responsive at first glance anyway, which isn't all that suprising.

The freezing could still be due to a threading issue, I really should double cehck and make sure that all shared data is being locked when it should again.

I'll look at the update pause thing, it's just a matter of pausing and restarting the net thread, but I'm not sure how to capture this for everything in the form. As another note, by far the most time is spent in the drawing function, ~26%, while the netthread comes in second at ~6%.

[cavemanbob]

The big packet thing works perfectly, and I tracked down what I think might have been causing most of the problems in the 1.8 release. It seems that the X Y Z coordinates I added to the listbox take a REALLY long time to update, after removeing the updates on those it runs way better. A new test version will be ready tommorow around noon cst.

[Sixes]

I can't help feeling your going down the wrong path with this client pulls paradigm.

What were you trying to fix? What was wrong with the server push method?

[lane]

Just a note on the Test app. Been working fine for about 2 hours now concurrent with MQ as well.

Client and server both running on notebooks over a wireless lan, wiht maybe 512 meg in one p'uter and 384 in the other. Win2K pro on both.

-Lane

[Proxeneta]

It seems that the freezing problem clearly only occurs on systems running pre winXP. I am running WinXP home for the client, and It seems to run just fine. But when I try to use it on Win98 I get immediate freezing as soon as I start to click on skittles, ect. I suggest using Winxp for the client with v1.8 and a winxp or below server with 1.5

[MrDoh]

Proxeneta,

Using all XP would certainly be wonderful, but isn't going to be practical for everyone. If I had a second machine that I could run XP on, believe me, I would be. If I had the mney to go build another PC, it would be XP, just like I run on the server/EQ PC.

My lockups were happening just as frequently with the pre 1.8 codebase.

This is a .NET application, so it should not *require* XP, but rather require .NET, which is available for many win-based platforms.

And, I also must respectfully disagree with your client-side pull observations. If the server just "spams" all the packets with no control from the client, I think you would be asking for trouble. At least with the client-side pull, there is some sort of flow control, which I believe did not exist in the "spam" code.

Just my .02

Mr. Doh

[Alfred]

Originally posted by Sixes
I can't help feeling your going down the wrong path with this client pulls paradigm.

What were you trying to fix? What was wrong with the server push method?

For slow PCs, the server push method simply wasn't working with the client design as it stood. Would lock up tight. Now it works... very slowly but it works.

Now that seq is working, and linux simply isn't a big of a resource hog, I won't have to struggle with a .net app on a PII 300mhz.

But keep up the good work CMB.

/cheers

[cavemanbob]

-- I can't help feeling your going down the wrong path with this client pulls paradigm.

What were you trying to fix? What was wrong with the server push method? ---

The problem with this method is that on slower PC's they appear to be able to ovverun their internal TCP buffers at which point something bad happens and the server locks on a send. In the end I like this setup better anyway, if I set the delay to 0 it updates really smoothly, it uses a LOT of network bandwith, but I don't really care.

Using XP is completely unnecessary, I have never started this application on XP. I run Win2k sp1, Win2k sp2 flawlessly and occasionally win98, but it doesn't work as well.