LOY problems, continued

[MrDoh]

Caveman,

I tried the offset you gave me. Oddly enough, that offset seems to work fine in the pre-LoY zones, but still the same in LoY.

I can say that watching my network traffic, I can tell you that after the very first update to the client, there is no more traffic generated.

I can also say, on that first update it draws the map corectly. It also places the circle/line pointer to the proper location. It does not, however track with you when you move. (obviously, see above, no network traffic between myseq server/client) I then shut the client down, move to a differnt position, and restart (just the client), and it once again, draws the map, places the pointer to the current position (where I moved too), never shows the spawn list, and doesn't update my position anymore. Once again, network traffic ceases, and still the client shows as it is still responding, and all the buttons and options work. (zoom, etc)

Please give me an idea if there is any other troubleshooting that I can do to try to help find the solution until we manage to get you LoY. If you let me know, and with minimal instruction, I'm sure I can do whatever may be necesarry.
Also, if you'd shoot me a PM, I think we can get around the downloads that are normally required. I remember the days of dialup and feel you pain. hehe

Mr. Doh

[cavemanbob]

Does the server drop back to the waiting state after the data stream stops?

I'm going to put a simple optional debug mode into the new server version for today, at least it'll maybe show where it's getting stuck.

[MrDoh]

No, the server seems to stay connected.
Infact, I can hit stop, and it does go back to waiting for new connection..., and then hit go again, and see the new connection from... message. I also, see that initial update happen again. When I press stop, I see some traffic occur (hopfully, an orderly disconnect.)

I still can't determine whether it's the server not sending, or the client not asking, as I do not know the push/pull structure of the client/server.

I can say, I never have to restart the server portion currently, running with that new offset.

Mr. Doh

[cavemanbob]

Grab the new client & server and start the server in debug mode, it'll dump a bunch of info about outgoing packets.

[MrDoh]

Well, here is what I have found...

1st, when installing the new client, you must delete prefs.xml if you have one. Unless you do, the client gives an error after clicking ok in te options menu. (which by the way, change to the default server ip)

2nt, The server portion never actully creates the dubug file. It does however give some information on the screen. Here it is:

new connecion from: ...
...
...
...
SPAWN PACKETS:


That's it. It stops there, and never goes any further. I have waitied on it for over 5 minutes.


When I press stop, the server then actually puts "sent" by the "SPAWN PACKET:" , and continues on to say END PACKET: sent, abd goes back to "waiting for new connection..."

This was tried with the alternative offset that you provided in the previous thread, not the default that the server portion knows.

Hopes this help a little, but it doesn't look as promising. If I can get a down and dirty explination on what I need to capture the memory, I'll be glad too. I'm really wanting to learn some more of the internals of all this nifty stuff, and this would probably help me anyway.

As always, please let me know if there is anything I can do.

Mr. Doh

[cavemanbob]

Good point on the first bit, I forgot about that, It should be doing something about that error.

OK that's what I thought was happening so it was very helpful. If you can rebuild the server uncomment the printf in these lines:

assignSPAWNtoSEND(&si, &sisend);
//printf("%s\t%s\n", si.Name, sisend.Name);
if (send(newfd, (char*)&sisend, sizeof(sisend), 0) < 0) {

That'll dump the mob names as they decode so you can see what 's going on a bit better

If you can't rebuild it let me know and I'll send you an exe to do it. I wouldn't think they'd change the spawn strcture only in LoY zones, but who knows...

Has anyone tried LEQM in these zones to see if it works right?

EDIT: Not paying attention...

[Nurseling]

That is the same point mine locks up in now in any zone.
The old server and old myseq still work 90% of the time though

[cavemanbob]

Actually now that I read MrDoh's post again it looks like it's probably getting stuck on the send. I think this is actually a network problem that's been lurking in here for a while...

As an afternote, I'm going to try something new. Rather than have the server spamming data and having the client try to lock onto it, I'm going to try setting this up to have the client request data and the server sends a bigass packet all at once. This will also allow compression as an option.

[Elyon]

ON the New 1.8 Client and 1.5 Server, the Circle doesn't move and when I click on any of the skittles, it doesn't highlight anything on the left. You can see my toon moving, but the circle stays put. If you click on left side, it draws a line to mob, but not in reverse.

[MrDoh]

I did finally manage to get the program compiled. I didn't realize it, but I had to explicitly include wsock32.lib. Interstingly, my compiled version is MUCH larger than yours, weighing in at 193KB. I personally am currious about why that is because I'm still learning. Do you have to include that on the command line, or anything when you compile? I'm I including libraries I don't need, or did you edit the libraries to remove functions you don't use?

I have the following new to report...

It very quickly displays a very large list of mobs.
And it seems to be the correct list. This is very good news!
It also does this over, and over, and over again. (which seems to be how the debug mode works) At the lend of the list everytime, I do get the END PACKET: sent prompt, but I am not actually seeing the traffic on my network. Interesting, when I press stop on the client, the server keeps showing me the list over and over still, and never goes back to "waiting...".

I also added a little code to define a level 2 debug that specifically outputs the standard debug information, but also the spawn list information.

As for your suggestion to the cause of the problem, you might be right. I have noticed with this version that everytime the client locks up to the point (which these new versions tonight seem to do much more frequently) where I must use "end task", the server seems to be stuck at the same SPAWN PACKETS: prompt.
When I do end task, the server goes back to waiting for connection.
Is the client waiting on the server to do something, and at the exact same time, the server is waiting for the client to do something? Could it be that the data is being transfered to fast for the client to keep up with? Just a thought, remember I'm just learning here. :)

Sounds like we are getting closer and closer.

Thanks!
Mr. Doh

[cavemanbob]

First off, there are a couple of huge nasty bugs in the 1.5 serVer code, they likely wouldn't affect what you're seeing, but the new 1.5a code has more return checking anyway.

The size difference is likely because your build is a debug build, it doesn't strip out unused stuff so they get real big.

What I think is happening is the client sometimes can't keep up with the speed of the datastream for whatever reason, the internal TCP buffer fills up, something goes horribly wrong silently and the server blocks forever on a send.

There are 2 options I'm thinking of to try to solve this:
1. Convert the server to send one big packet when the client asks for it. (The better option)
2. Just have the client ask for a packet, then the server sends it. (The easier option)

So I'll probably shift the timing to the client nomatter what, which was a better solution anyway and implement option 2 and if that either doesn't work or the other one doesn't look that hard shoot for option 1 next.

Of course I could be completely wrong too :)

[MrDoh]

couple of questions and comments based on your last message, who knows, I may hit on something hehe...

1, currently, it sounds like (please correct me if I'm wrong) the client sends an initial packet to the server. At that point does the server just flood the client, or does the client send out acknowledgement packets back to the server to verify recipt. (I could break out the sniffer and check this for myself, but it would be much quicker to ask) If not, can't the server wait for an acknowledgement package that the client could sent it? (I know this doesn't solve the problem, but it might be a problem for someone at somepoint.)

2, is there a way the client can time out after waiting a certain period of time for a packet to be completely recieved if it never is?

3, also makes me wonder, is the problem packets that (at least some) are too large, or too many itty bitty packets (at times) that could be combined into a larger one?

4, If numer 3 doesn't help, (and I relize this one could possibly be quite a pain, if not imopossible to impliment) would it be possible to "encode" certain data in the packet to make is smaller?
(that makes no sense, so i.e.,
instead of sending the level as "32" or whatever, making it static that Z=32, and the server would receive the Z and translate it to 32. ) In that example, it saves you very little, but is "a_skeleton" were to equal "Z" you would see a significant savings pretty quick in your packet size. BUT that would also mean (i figure) that there would have to be static lists built into the server and client, and that would make things very large, and have to be updated based on new mobs, zones, etc.

The one last thing is, you would really want the client to pull (request) the packets for the server. For one reason, exactly as is happening, that surely the client wouldn't ask for more packets than it could handle. With the pull scenario, you could put an option in the client of how often you would like the packets requested from the server.) This would be like the server memory read timer, but instead of saving CPU, you would be saving bandwith for those that might have a problem with it.

I hope some of this made at least a little sense.
It's too much to hope that some of this may have actually helped.
Please set this noob programmer straight!

Hopefully helping,
Mr. Doh

[cavemanbob]

I've done a quick change to the server removing all the added error checking code and adding just the one line to activate the moveing mob lines. There's something about the new error checking that was breaking zoning... Grab the 1.5b

1. The client at the current time never explicitly send a packet to the server, the connection is taken as a start command. This is part of the reason I want the client to ask for packets rather than be constantly spammed with them. I smell a race condition in here...

2. This is a reason I want the client asking for packets rather than being flooded...

3. Yes, but dealing with larger packets is kind of a pain because the size is variable and they'll likely come from receive in smaller chunks just because of the way network sockets work.

4. Interesting, but just zlib'ing the packets as a whole would probably be enough. There's a LOT of wasted space still.


The next client will poll the server for packets for sure now, one at a time for now, maybe dump them all at once later. It's jsut easier and it should fix some problems I hope.

[cavemanbob]

I've done a quick change to the server removing all the added error checking code and adding just the one line to activate the moveing mob lines. There's something about the new error checking that was breaking zoning... Grab the 1.5b

1. The client at the current time never explicitly send a packet to the server, the connection is taken as a start command. This is part of the reason I want the client to ask for packets rather than be constantly spammed with them. I smell a race condition in here...

2. This is a reason I want the client asking for packets rather than being flooded...

3. Yes, but dealing with larger packets is kind of a pain because the size is variable and they'll likely come from receive in smaller chunks just because of the way network sockets work.

The next client will poll the server for packets for sure now, one at a time for now, maybe dump them all at once later. It's jsut easier and it should fix some problems I hope.