Gate Transfer / Vendor Problem

[Demosthenes]

Hello,

I am currently running Windows XP SP3.

Probably around 10% of the time I try to gate to a different sector, I get a loading screen like this:

http://img708.imageshack.us/i/bug1n.png/

It's just like the beginning loading screen, only the "Loading..." bar in the bottom right is there. Note there are no red circles or From / To transferring bars.

If I alt-tab to the command prompt, it shows this:

http://img97.imageshack.us/i/bug2r.png/

before I terminate it.

It varies between this (I force close it eventually using task manager) and crashing to desktop with this in the command window:

http://img268.imageshack.us/img268/1648/bug3c.png

It has the normal loading screen with the To / From message bars and the red circle(s) when this happens, so I'm not sure if this problem is related or not.

Also, different problem but possibly related, I've been effectively stuck right between clicking an NPC (vendor or otherwise) and the conversation window popping up, with no crashes ever from that problem, just me stuck. Exiting to Character Selection solves this problem. Here's a screenshot:

http://img504.imageshack.us/img504/4439/bug4u.png

With both of these problems, there will be times where it's happening all the time to the point that I'm unable to do anything, and hours gone by with no problems whatsoever.

Thanks in advance for your help, it's awesome what yall are doing here

Edited May 7, 2010 by Demosthenes

[C Del[IS]]

These both seem to indicate communications breakdowns between you and the server, which I'm afraid we can't do much about at the moment. Does this seems to happen at particular times? I think packet drop could be larger during peak usage (I would suspect that especially if you're on cable). Further server development will make this issue better for you; we still have work to do on the communications system. Lastly, what is your network setup? (routers, modems, etc.) Perhaps you have a piece of hardware contributing to the problem.

[Tienbau]

packet drop shouldn't be affected by how many users are online, every player is sent a packet update every 100ms no matter what the loading is - I've noticed some players just have a much higher packet drop than others. Maybe I'll put some stats into a database so we can plot some graphs of the players most affected by this and try to determine the cause.

I've noticed my packet drop is practically zero, even though I'm further away from the server than most people (unless we have any players on the ISS ). However if I (or wifey ) start running Vuze my packet drop suddenly increases.

If you are running a Bitorrent client or p2p (or a certain someone on your LAN is) you could try switching it off and seeing if you get a better connection.

[Numiah2]

Time to insert stupid question.

How was it handled in live ? A lot of us were on 28k or 64k (128k with dual ISDN).

I don't recall any issues with the amount of data sent and dropping packets.

[C Del[IS]]

In live, EA/Westwood had full control over, and documentation on, their communication system, a luxury we don't have. Our communication system is improvised (brilliantly so, of course ), so it doesn't always work 100% correctly.

Tienbau; from what I've seen, I think packet drops during sector handoff are the main problem. Granted, I haven't been messing around with this for quite a while now, but when I was writing my chat tool I noticed that packet drop can really be crippling during handoffs, as there doesn't seem to need to be a handoff acknowledgement. It seems like the proxy should need to ack the handoff before the server stops trying to hand the client to a sector; does it?

[Sunnyg]

Another thing to consider is wired vs wireless.

My ping is 11ms and I have a 30Mbps/2Mbps cable pipe.

I'm in between jobs at the moment so I can put in 6-8 hours a day and have done so the last two weeks. My main PC drops once a day, after a full day's worth of playing.

My tablet PC which has an alt that follows my main around drops several times per hour. However, it's wireless. I'll connect another cable to it and see if stability improves or not and report back.

Edited May 7, 2010 by Sunnyg

[Demosthenes]

OP here,

I ran a ping logger through CMD prompt and it looks like I'm getting timeout or >1k once every 20-60 pings. I'm on Comcast cable with a (I know it's shitty) Linksys wireless router. Once I get back to the computer in question (I live in a different city during the weekends) I'll try a hardline and let yall know the results. As I recall now I've been having random connection issues for quite a while, don't know why I didn't add 2 and 2.

As aside note, this game apparently handles packet drops incredibly well when there's no server handoff like you were saying. I rarely have a problem other than the ones stated above.

[beisser]

Time to insert stupid question.

How was it handled in live ? A lot of us were on 28k or 64k (128k with dual ISDN).

I don't recall any issues with the amount of data sent and dropping packets.

didnt they use tcp instead of udp on the live servers?

[Tienbau]

didnt they use tcp instead of udp on the live servers?

Hi (sorry Cdel, I keep doing this) -

they used UDP only. If you want to check download a copy of the old 'alex packets', which are the win p-cap/wireshark captured packets from live, which very clearly show they are all UDP. We were unable to completely crack the generation of that UDP format, even with the expertise of crypto geniuses like Agfot. I spent a month back in 2008 trying to convert the server to a pure UDP format like live but managing the cycling crypto keys just had me baffled.

Luckily there was an old TCP backdoor into the client, but this backdoor was a development one, and apparently never fully perfected.

Two things happen to kill the link to the server:

1. About 1 in 64 sector logins produce a crypto key error, which kills the client link. Although this isn't much, with 300 players online it's going to happen apparently quite frequently. This has been a problem since I joined the project in 2006. I have worked out a workaround for this but I haven't got round to coding it yet. It appears to have gotten worse only because the rest of the system has improved so dramatically.

2. p2p/bittorrent can cause too many packet re-requests for the recovery system to cope, although (1) is a much worse problem.

Our UDP link (which we designed from scratch) from server to Net7Proxy is pretty much 100% reliable once the actual login is complete, but the real weakness is that crypto key error thing that happens when the client tries to establish a new TCP sector link to Net7Proxy. Once I implement the workaround (essentially to get the client to renegotiate another sector link).

But essentially what Cdel says is correct in terms of WW having complete control over their connection between the client and server - we're having to work around the unfinished development TCP link they (fortunately) left in.

Hope this clarifies where we're at currently ...

cheers,

TB

[Numiah2]

Thank you very much for that reply TB !