Print

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

[GonoszTopi]

perform one more connection attempt

wrong. Instead, it should check the "existing" connection, whether it is still connected, or not. I agree with the error page.

[lfroen]

wrong. Instead, it should check the "existing" connection

No, that's wrong. Consider that your existing connection is dead (no matter reason), and you're not "still connected". Now what you do ? Silently exit ?!
You can check whether existing connection is still "alive" whatever it means, but be ready that it's not. And if it's not - you have to reconnect.

[Vollstrecker]

Jep, and when you implemented that reconnect, amule can check if amulewb is already running, and then not starting a new one.

[lfroen]

amule can check if amulewb is already running

I have serious doubt about this. How exactly do you check this without knowing pid upfront ? Not that this is impossible, but neither trivial.

[GonoszTopi]

You can check whether existing connection is still "alive"

That was what I meant.

And if it's not - you have to reconnect.

nope, instead

if not - display error page

The error page might have an option to try to reconnect (option == a link)

amule can check if amulewb is already running

I have serious doubt about this. How exactly do you check this without knowing pid upfront ? Not that this is impossible, but neither trivial.

You can check whether amuleweb is running or not (not trivial, as lfroen said), but you'll never be able to find out whether this running webserver instance wanted to connect to you.

Just imagine, that you start amuleweb, that connects to amule somewhere else. Then you decide to run amule too on this local machine. Amule would find out that a webserver is running, so it wouldn't start another one, but now it should.

[Vollstrecker]

You can check if you get an answer on webserver-port. 4711 I think. When you get an answer on this port, amuleweb is running. I don't think that it works if  you want to start a second one, on the same port, because the two amulewebs don't know to which of them you are talking. No matter if it wants to connect to you or not.

[GonoszTopi]

You can check if you get an answer on webserver-port. 4711 I think.

Yes, it is the default port. But nothing keeps users from changing it, so...

[Vollstrecker]

When I see right, you can specify only the port where amule accepts EC, not the port amuleweb listens on commandline. So I think that port is in amule.conf or remote.conf. So amule can see which port he has to check.

[GonoszTopi]

When I see right, you can specify only the port where amule accepts EC, not the port amuleweb listens on commandline.

From amuleweb man page:

Code: [Select]

      -s, --server-port=
              Webserver's HTTP port. This is the port you can point your browser to (default: 4711)

So I think that port is in amule.conf or remote.conf. So amule can see which port he has to check.

Well, remote.conf... which user? Amuleweb can be run by any user, not necessarily by the one who runs amule. The only requirement is that (s)he: 1) has an appropriate remote.conf file (or any other name, see the -f, --config-file command-line option), 2) supplies adequate command-line parameters, 3) answers the questions from amuleweb.

Actually, it could be implemented:
1) amule check for a process with a command name "amuleweb{DLG}"
2) check the command-line of the process for a -s switch
3) if not found, get the owner of the process
4) if owner of the process is not the current user, and we are not root, then give up
5) check the command-line of the process for a -f switch, if not found use "remote.conf" as config file name
6) read config file from the detected user's home directory.

I think it 1) doesn't wort the effort, 2) opens security holes, 3) people used to not like when a process just reads their secret files without a notice.

If you disagree with the above, just let me know :)

PS: And we still didn't care about things like:
1) what if a user renames amuleweb to something else, just for fun? (like amule-webserver, and leaves amuleweb as a symlink to the new name)
2) what if I use amuleweb to monitor another amule(d) somewhere else?
3) amuleweb behaves differently when started manually, manually with the -L switch, automatically...

So, certain cases can be detected, but it's more error-prone than useful.

[Vollstrecker]

Another optoin would be, that amule sends a message to conected amuleweb-processes, that it terminates. Amuleweb can then terminate, too. Without the amule process where it is connected to it is useless, and if somebody complains about that, you could add an option to remote.conf that lets amuleweb be running.

[GonoszTopi]

I also thought of it, but currently EC uses a polling mechanism (client ask something, core answers). No way to send a message from core to client. This would require rewriting EC sockets, etc (which will be done soon, so this might get implemented).

However, this is not a solution for situations when amule exits abnormally (i.e. crashes).

[lfroen]

Without the amule process where it is connected to it is useless

did you bothered to read thread above ?
If amule is unexpectedly quit - webserver should notify user about it. That's what it exist for - monitor remote amule.

Actually, it could be implemented:
1) amule check for a process with a command name "amuleweb{DLG}"
2) check the command-line of the process for a -s switch
3) if not found, get the owner of the process
4) if owner of the process is not the current user, and we are not root, then give up
5) check the command-line of the process for a -f switch, if not found use "remote.conf" as config file name

GonoszTopi: this is all over OS dependent. Even when available, you may not have permissions to access command line of other user's process. Consider situaltion when amuleweb started under other username.

But, let's stay focused. GonoszTopi - instead of trying to think about some imaginary scenario, where several amule's and amuleweb distributed over network and communicate with each other, let's make common case work correctly. And THEN think about exceptions.
Have you ever heard the word "usability" ?
The common case is "amuleweb" is started by amule (obviously on same machine) but amule(d) has quit unexpectedly. What we do ?

The error page might have an option to try to reconnect (option == a link)

You did not answered WHY it should be AN OPTION ? Why user would NOT want to reconnect ? Does (s)he enjoy looking in the error page ? Instead of including such link, just do it without bothering to ask user. This will provide match better experience.

[lfroen]

Now, to the case of "amule set to start amuleweb automatically, but another one trying to reconnect". Obviously, both has been started with same options, and trying to listen on the same port. So, when amuleweb encountered situation that port can't be bound, it must simply quit, and we left with one amuleweb that reconnects and everything works as usual.
Even if user changed port in-between, nothing wrong happens - we will have 2 amuleweb's serving same page on 2 different ports.

[GonoszTopi]

You did not answered WHY it should be AN OPTION ? Why user would NOT want to reconnect ? Does (s)he enjoy looking in the error page ? Instead of including such link, just do it without bothering to ask user. This will provide match better experience.

And did you think of HOW that "unexpectedly quit amule" gets restarted?

There should be an error page, that notifies user that something is wrong. Then the user can take appropriate steps (i.e. restart amule), and reconnect.

For being user-friendly, amuleweb can first try to reconnect and if that fails, only then displaying an error page (to deal with auto-restart scripts).

[GonoszTopi]

GonoszTopi: this is all over OS dependent. Even when available, you may not have permissions to access command line of other user's process. Consider situaltion when amuleweb started under other username.

But, let's stay focused. GonoszTopi - instead of trying to think about some imaginary scenario, where several amule's and amuleweb distributed over network and communicate with each other, let's make common case work correctly. And THEN think about exceptions.
Have you ever heard the word "usability" ?

describing difficulties and drawbacks != implementing

Consider situaltion when amuleweb started under other username.

see 4)