Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Pitxyoki]

I'm not sure if these should go as suggestions or as bug reports, but here it goes:

1. aMuleweb doesn't accept commands anymore.
  Since about version 2.2 or so, when running amuleweb, any inputted commands just do nothing. The only way to exit the program is by using ctrl+c, as opposed to typing the more tidy "exit" command that used to be available. I always thought there could be some future additions to amuleweb's command-line interpreter, but if this is to be removed, please also remove the message telling me to see the command list:

Code: [Select]

$ amuleweb
This is amuleweb 2.2.3
Enter password for mule connection:

Creating client...
Succeeded! Connection established to aMule 2.2.3

--------------------------------------
|          aMule Web Server          |
--------------------------------------

Use 'Help' for command list

2. amulegui could be nicer on its output when failing to connect. I did some tests and this is what I found:
- If you supply a correct address with a correct password, it connects and everything goes fine;
- If you supply a correct address with a wrong password, it will fail, but the program exits without any GUI output (you will only know if you are running it from a terminal);

- If you supply an incorrect or unreachable address, or if amuled is not running there, amulegui will get blocked, saying "Going to event loop..." on it's standard output (and no GUI output);

- only If you don't give a password, amulegui will show a GUI window saying the connection failed (though it doesn't explain why).

I think all of these situations (except when everything supplied is correct) should provide a notification window to tell the user what just happened. Especially when amuled is not running on the target machine, the program just hangs and nothing is shown, which can be confusing sometimes - you never know if it failed or if it is waiting to connect, or until when you should wait for it to start.

[GonoszTopi]

1.

please also remove the message telling me to see the command list

Done on the 2.3.x branch, I guess it can be backported for the upcoming 2.2.4.

2. agreed.

[Stu Redman]

2. fixed 

[Pitxyoki]

2. fixed  

2. is still not fixed for some cases.
Examples:
  Input a valid address (e.g., www.google.com) that is reachable but doesn't have aMuled running.
  Input something that can't be resolved or connected to (e.g., IMPOSSIBLE-TO-RESOLVE, 192.168.2.0).

The window will disappear and nothing will happen in both cases.

I may be wrong, but apparently only if the destination can be contacted and it responds with a RST packet will the error window appear.

[Stu Redman]

Same here (with current SVN).

[Pitxyoki]

  Ok, so I've been testing this a bit more and here are the most recent results:
  All of the expectable situations produced an error window, except when the given name can't be resolved by DNS. On my previous post, I was actually waiting for too little time for some of the other tests to fail.
  If I input something like "asd", the DNS server responds with "No such name". amulegui will not send any TCP packets from then on and nothing happens anymore. amulegui just sits running in the background -  I started it from a terminal, so I'm sure it is still running, just waiting for something (possibly for the connection to timeout - but it didn't even try to start such connection, as the name resolution failed).
  I've been sitting here in front of Wireshark for about 20 minutes now and nothing happened after the attempt to resolve "asd".



  The rest of the tests I made led me to the conclusion that if the given name can be resolved, or an IP (reachable or not) is provided, amulegui will send TCP packets, trying to establish the connection. After this has started, if no answer is received after approximately 3 minutes and 30 seconds (on my machine), a window with the error message appears.

Code: [Select]

Outside world tests:
name that can be resolved (google.com) -> times out after 3m30s
address without amule running (213.13.146.140) -> times out after 3m30s

Local network:
address with machine turned off (192.168.2.176) -> times out after 3m30s
resolvable name without aMule running (C-7) -> times out after  3m30s
        address without aMule running (192.168.2.148) -> times out after 3m30s

  All of these tests make TCP packets get out of my machine. After trying for ~3m30s without any response, the error window appears.

  So, I'd suggest adding a timeout for these attempts. Even if a machine is reachable, if, say, after 30 seconds there is no response, it should be reasonable to at least tell the user that the connection is not available (or, at least, warn him that it is very likely to fail or have errors).


  Also, hiding any window from the user gives a bit of a "loss" sensation. Between the moment you click "OK" and you have any subsequent visual input, you don't know if something went wrong or if there will be any more output. I'm thinking that a window displaying "Establishing Connection..." with a possible "Cancel" button would be nice for this.


  Now that I think of it, all of this could be combined into something like:

  First, the current window where the user inputs the IP/address + port + password is displayed.
    - after clicking OK, that window wouldn't vanish, but the input boxes would be greyed and a message saying "Establishing Connection..." would appear on the same window (perhaps in something resembling a status message), with some kind of visual input (a jumping rabbit comes to mind  . An "Abort Attempt" button would be nice at this stage too.
      - if after 30 seconds the connection is not established yet, a warning would be displayed in the same window, telling the user that this attempt might fail.
      - if after 10 minutes the connection is not established yet OR the connection times out, abort the attempt and show the warning and _unlock_ the user input at the login window.

This would make the login process more intuitive and would not let the user be left asking "What's happening now? Did it crash? Should I just wait? Should I launch another amulegui instance?"

I could also very well try to program this and submit a patch... Maybe when I have the time (*laughs dementedly*) I can try to do this...


I'm using amule 2.2.5 using the Debian packages at the official testing repositories.


Egh... I just noticed that this post grew immensely by itself... I hope you can reproduce this and consider my suggestions.

[Stu Redman]

I think your suggestions sound good. 

If you try something yourself, please base it on current SVN, NOT on 2.2.5.