Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
hyperion
Newbie


Joined: 12 Nov 2007
Posts: 6

PostPosted: Tue Mar 29, 2016 3:56 pm   

disconnect on many commands
 
Running cmud pro 3.34, I now have an issue I haven't seen before.

On long fast speedwalks (over 250) or long series of commands (probably the same), I get disconnected from the mud if I don't break them up with some delays.

I'm told the mud hasn't added anything new to throttle, so any ideas would be most welcome.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 3698
Location: Pensacola, FL, USA

PostPosted: Wed Mar 30, 2016 4:59 pm   
 
Have you tried it with the mapper in safe or slow mode?
The scripting tab in prefs allows you to throttle your own speedwalks.
_________________
Windows 10 Home Premium 64-bit
AMD Phenom II x6 1055T 2.8GHz 16GB
CMUD Pro v3.34
Reply with quote
hyperion
Newbie


Joined: 12 Nov 2007
Posts: 6

PostPosted: Fri Apr 01, 2016 2:38 pm   
 
Yes, and it is fine with either of those. However, it is not just speedwalking, it is any long series of commands without artificial breaks inserted by me.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 3698
Location: Pensacola, FL, USA

PostPosted: Mon Apr 04, 2016 7:14 pm   
 
Is that an issue that crops up regularly?
Speedwalking is the only time when I would ever send that many commands at once.
For throughput of game grinding, I find many commands could never be processed if all sent at once because of the various pauses games put into place to represent doing the activity, and to slow down character progression.
As such, triggers based on success/fail messages work better, and keep the queued command count down to reasonable numbers.

Maybe if you insert a few #WAITs in there, even if only for 0 milliseconds, it would give the impressions they are not all sent at once.
What exactly are you doing anyway?
_________________
Windows 10 Home Premium 64-bit
AMD Phenom II x6 1055T 2.8GHz 16GB
CMUD Pro v3.34
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Mon Apr 04, 2016 9:03 pm   
 
I am going to hazard a guess that the problem is a router some where between you and the MUD viewing the many packets being sent as a DOS attack. You can try a few things to see if this idea is correct. First try to get disconnected by entering the following in the command line:
#LOOP 300 {#CR}
You may have to adjust the count of the loop. If that does a disconnect then the next test is to use the same count needed to disconnect:
#SEND {%repeat(%cr, 300)}

Only do the second test if you get a disconnect with the first one. If you can't get a disconnect with the first then you will have to try again with some harmless command, and you should suspect the MUD as being responsible:
#LOOP 300 {#SEND {harmless}}
#SEND {%repeat(%concat("harmless",%cr),300)}

If the first disconnects and the second doesn't then it is a router issue, you might start by testing to see if your own router is the cause. Assuming a cable modem, you would do the test by plugging your computer directly into the modem. If the disconnect goes away then you might look to adjust your router settings.
If both disconnect then it is the MUD responding to having too many commands at once.

The way to block it is to create an input queue that checks how fast your sending commands. Start with an #ONINPUT to capture everything. You will have to record the last time that a command was sent, for that you want the higher precision Predefined Variable %secs and you may want to allow some number of command to all go through so a sent count. If your count is at the limit you choose for the amount of time then you would put the command into a list using %additem, enable an #ALARM with #T+ to send the next group of commands, and finally #GAG the command to stop it from being sent at this time. In the #ALARM you have to bypass your queuing #ONINPUT, this is done using #SENDRAW. You would use %pop to grab the first item off the list however many times is safe, and then update your record for the last time a command was sent. If the queue is empty then the #ALARM should turn itself off with #T-.

If you use other #ONINPUTs then you would set the priority of this one to be last so that all those others can do there work. I hope my description is thorough enough, I can't write it for you since my machine Windows machine is currently down.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
hyperion
Newbie


Joined: 12 Nov 2007
Posts: 6

PostPosted: Sat Apr 23, 2016 3:09 am   
 
The CRs worked, but a mud cmd disconnected me. Also, oddly, cmud thinks I am still connected (session timer keeps ticking.

Thanks for the troubleshooting advice. Looks like it is the mud.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net