aMule Forum
English => en_Bugs => Topic started by: wild_oscar on April 28, 2008, 01:02:00 PM
-
I have SVN 20080423, running amuled on a remote pc and connecting through amulegui.
After a few hours of connection in amuled, amulegui is having this behaviour:
- It connects to amuled and window is displayed. However, everything is blank except the server list and shared files list. Uploads/downloads don't show, current U/L speed and connection status is not showing.
Search does not work either.
If I delete the .aMule directory in the amuled computer and copy these backed up files
# clients.met, stores the other clients credits. When you download some from a client, you'll store in this file how much you have got, so you can promote that client when it will be in your upload queue.
# server.met and staticservers.dat, it contains the saved eMule servers.
# ipfilter.dat and ipfilter_static.dat, which contain the IP denied to connect/share files with you.
# emfriends.met, it contains the friends list.
# addresses.dat contains a list of URLs from where aMule will download server.met files to merge with its current server.met file.
# cryptkey.dat and preferences.dat, they uniquely identify you to other clients, so you can keep credits to their side.
# key_index.dat, load_index.dat, nodes.dat, preferencesKad.dat and src_index.dat are Kademlia files.
(from wiki), it will connect without a problem and start hashing the files.
In logfile everything seems to be ok:
2008-04-28 11:05:01: ExternalConn.cpp(307): Access granted.
2008-04-28 11:05:16: ExternalConn.cpp(117): External connection closed.
2008-04-28 11:07:55: ExternalConn.cpp(218): New external connection accepted
2008-04-28 11:07:55: ExternalConn.cpp(252): Connecting client: amule-remote 0x0001
2008-04-28 11:07:55: ExternalConn.cpp(307): Access granted.
2008-04-28 11:11:36: ExternalConn.cpp(117): External connection closed.
2008-04-28 11:12:13: ExternalConn.cpp(218): New external connection accepted
2008-04-28 11:12:13: ExternalConn.cpp(252): Connecting client: amule-remote 0x0001
2008-04-28 11:12:13: ExternalConn.cpp(307): Access granted.
2008-04-28 11:12:19: ExternalConn.cpp(117): External connection closed.
And amulecmd can connect without any issue.
By the way, amuled is currently running with gdb, as it was crashing randomly.
-
On an update to the problem.
1) Amulegui not connecting ok
2) Backup and remove .aMule/*
3) run amuled. It will complain about remoteconnections and not start, but create .aMule directory
4) Copy the following files from the backup:
clients.met
server.met
addresses.dat
cryptkey.dat and preferences.dat
key_index.dat, load_index.dat, nodes.dat, preferencesKad.dat and src_index.dat
Amulegui starts without a problem.
5) Copy
known.met
known2_64.met
Amulegui will not work correctly.
6) Remove known.met
Amulegui will work correctly again and logfile will show it's creating hashes for the files.
7) After a few hours, amulegui will stop working again
(by the way, why is the file known2_64.met instead of known2.met?)
-
Issue persists. Amulecmd and amuleweb work correctly, but amulegui's connection is highly irregular, working correctly only once every 10 times...
-
Well, it did work, and rather well. Right now it's quite broken however. I don't see a single download anymore. :(
-
Well, it did work, and rather well. Right now it's quite broken however. I don't see a single download anymore. :(
Same here.
Have you checked http://bugs.amule.org/view.php?id=1146 (http://bugs.amule.org/view.php?id=1146) to "request" a bug fix?
It seems that if I remove known.met amulegui will work fine for a while (until that file is rebuilt, apparently). Can you test if this happens with you as well?
-
On which machine ? The machine running the daemon/monolith or the machine running the remote-gui ?
-
On which machine ? The machine running the daemon/monolith or the machine running the remote-gui ?
The one running the daemon.
-
I've played around a bit with it and found:
- The remote gui protocol is very sensitive to dropped packets. If packets are lost, the whole connection goes out of sync and displays nothing useful anymore permanently (until you restart the remotegui).
- Remote packets are affected by the upload bandwidth throttler. That's why deleting known.met helps. It breaks your upload for a while, because aMule has to rehash all shared files. And during this time, the remotegui works better because there is more UL bandwidth available.
- Even with UL bandwidth = 0 (unlimited) it works sometimes, sometimes not (though better than with limit).
- with lots of files it works worse than with few, because more data has tobe transferred.
Looks like the protocol needs some rework...
-
I've played around a bit with it and found:
- The remote gui protocol is very sensitive to dropped packets. If packets are lost, the whole connection goes out of sync and displays nothing useful anymore permanently (until you restart the remotegui).
- Remote packets are affected by the upload bandwidth throttler. That's why deleting known.met helps. It breaks your upload for a while, because aMule has to rehash all shared files. And during this time, the remotegui works better because there is more UL bandwidth available.
- Even with UL bandwidth = 0 (unlimited) it works sometimes, sometimes not (though better than with limit).
- with lots of files it works worse than with few, because more data has tobe transferred.
Looks like the protocol needs some rework...
Bare in mind that, in my case, it does not display anything useful anymore permanently, even if I restart remotegui. After a few hours, no matter how many times I start amulegui, I will never get a working gui, it will never display anything. Only deleting known.met will make info like upload and download list, U/L speeds, search and info on the connection status (green arrows of kad and server) show again.
-
Please set your upload speed to 1 k/s and see if my theory is correct and remotegui works better then.
-
my connection issue amulegui+amuled concerns only the cpu power where amuled run
511 shared files, upload queue set to 10.000 clients, upload bandwidth set to 25Kbyte/s on 32Kbyte/s available
athlon xp2400+@500MHz (downclock): amulegui connects once in ten the first minutes (when the queue is short but upload is already at maximum speed), after sometime it does not connect anymore (queue becomes long and cpu utilization increases a bit)
it never connects also if the hashing is taking place or if the cpu system is used by some other application (i.e. amuled svn compilation)
athlonxp2400+@1GHz(downclock): amulegui connects to amuled 9 times on ten, connects also after sometime and during hashing, it does not connect if the cpu is used by some other application
i think that if i remove downclock (athlonxp2400+@2GHz) i will never experiment connection problems
- Remote packets are affected by the upload bandwidth throttler. That's why deleting known.met helps. It breaks your upload for a while, because aMule has to rehash all shared files. And during this time, the remotegui works better because there is more UL bandwidth available.
how can there be more UL bandwidth available if you just need to rehash 2/3 files (few seconds) for starting to upload again at maximum speed?
-
Please set your upload speed to 1 k/s and see if my theory is correct and remotegui works better then.
Following your suggestion, I tried that. I removed the known.met, changed UL speed to 1k and restarted amuled.
About 4-5 hours later, I can connect with amulegui but can't see the U/D queue already (although info on the servers is still present), nor can I perform searches, so I don't know if your suspicion is completely accurate...
-
In addition, why has this only been an issue with the latest SVN? With the Febuary versions (and 2.1.3) I didn't have these issues...
-
Looks like the protocol needs some rework...
Yes, it does. And aMuleGUI needs a lot of work too.
-
Looks like the protocol needs some rework...
Yes, it does.
No, it does not. Yet another EC re-write?!
Regarding "remote GUI over slow connection": this is plain tcp. It works bad over crappy connection, no news here. For GUI to work properly, you need timely updates. This doesn't compute.
-
Looks like the protocol needs some rework...
Yes, it does.
No, it does not. Yet another EC re-write?!
Regarding "remote GUI over slow connection": this is plain tcp. It works bad over crappy connection, no news here. For GUI to work properly, you need timely updates. This doesn't compute.
Bare in mind that I'm using amuleGUI on a local network, 100kbps, and that it used to work before.
-
how can there be more UL bandwidth available if you just need to rehash 2/3 files (few seconds) for starting to upload again at maximum speed?
After hashing (which will take more than few seconds with many large files) the files need to be published, and the be found by the sinks. That should take enough time to make a few successful remote connects.
No, it does not. Yet another EC re-write?!
Easy. 8) If amuleweb is not affected it might be just a problem of the remotegui-app.
Regarding "remote GUI over slow connection": this is plain tcp.
No, it's not. Plain TCP has no bandwidth throttler to consider.
I've also tested it with a straight 100Mbit connection. If it fails even there it's not very useful as it is.
Another thing that deserves a look is the go-to-the-background-and-wait-until-someone-kills-the-process-behaviour, if the connection can't be established. ;)
-
how can there be more UL bandwidth available if you just need to rehash 2/3 files (few seconds) for starting to upload again at maximum speed?
After hashing (which will take more than few seconds with many large files) the files need to be published, and the be found by the sinks. That should take enough time to make a few successful remote connects.
that is true only if you change also ip or tcp port when you delete the known.met
-
Even if not it will not upload until the first sink reasks, and they do that only every 30min or so. :P
-
Another thing that deserves a look is the go-to-the-background-and-wait-until-someone-kills-the-process-behaviour, if the connection can't be established. ;)
That's bloody annoying bug, I agree.
-
I've reported this bug a long time ago ( #1146 ), and i'm really glad theres progress! Thanks for all of your investigation.
I closed the issue prematurely, the problem is still there.
-
I think to have the same problem: my remote gui doens't update the download progress. It stops to work after few minutes and this happens only with the svn version. The older version of Amule Gui worked too but it's incompatible with the new Amule demon. I'm using Amule Svn 5may version on linux ubuntu 8.04 64 bit and the remote gui on a Windows XP laptop on a 54mbit wifi lan.
-
I think to have the same problem: my remote gui doens't update the download progress. It stops to work after few minutes and this happens only with the svn version. The older version of Amule Gui worked too but it's incompatible with the new Amule demon. I'm using Amule Svn 5may version on linux ubuntu 8.04 64 bit and the remote gui on a Windows XP laptop on a 54mbit wifi lan.
Any chance of prioritizing this issue, as it is making amulegui useless right now?
Please check these bug issues:
http://bugs.amule.org/view.php?id=1311 (http://bugs.amule.org/view.php?id=1311)
http://bugs.amule.org/view.php?id=1146 (http://bugs.amule.org/view.php?id=1146)
-
Easy. 8) If amuleweb is not affected it might be just a problem of the remotegui-app.
My amuled server is a K6-II, 64mb computer and all network clients are Pentium4. amuleGUI works only on half each. And amuleweb always works perfectly for all. Sure! amuleGUI have some problem connecting but I prefer using it for distributing loads (I'm waiting lfroen adding xinet support for amuleweb :P)
-
I've installed an amule SVN on a new, unused machine (with ubuntu).
After the night of running amuled, I seem to:
1) Be able to connect with amulegui in the same machine
2) Not able to connect with amulegui using another computer
UPDATE:
I've tried this running amulegui in two different computers and both cannot connect to the amuled I set up.
-
Please... what SVN versión (say date of SVN)
-
Please... what SVN versión (say date of SVN)
server1 (amuled+ working amulegui) - May 8 (yesterday's)
desktop1 (amulegui) - April 28th
laptop1 (amulegui) - May 8th (yesterday's)
-
Mind that only the same SVN version of amulegui and amuled/amule can connect.
-
Mind that only the same SVN version of amulegui and amuled/amule can connect.
Don't believe that's true, I've find that different versions of SVN can connect.
Either way, I have the same SVN version on my laptop whose amulegui does not connect to amuled in server1.
Moreover, my "desktop1 (amulegui) - April 28th" was connecting to a server2 with amuled of April 28th (the origin of the problem).
-
So, one month later...any news on this issue?
-
Hi.
I think I've found a solution. I attach a patch.
After some debugging hours, I think I've found was going on. amulegui has a PollTimer that does roughly this: 1. Sends a EC_OP_STAT_REQ request. 2. Sends again another EC_OP_STAT_REQ request. 3. If download view is active, it sends a EC_OP_GET_DLOAD_QUEUE request to get active files. If everything goes OK, amuled replies to these requests in the same order.
But it turns out that sometimes, I don't know why, amuled replies in wrong order, sending first the EC_OP_STAT_REQ reply, even if EC_OP_GET_DLOAD_QUEUE was requested before. When this happens the handler in charge of proccess the EC_OP_GET_DLOAD_QUEUE request receives instead the answer to EC_OP_STAT_REQ, and as it doesn't know what to do with it, it gets lost. But the worst thing is that since then all the protocol gets broken because the amuled responses are handled by the incorrect functions.
The patch I submit is a workaround to solve this situation when it happens. It does not solve the real problem, which is that packets are sent in wrong order. Anyway, to correct the problem the patch does the following:
In amule-remote-gui.h:
- HandlePacket in CRemoteContainer now detects if an "improper" response was sent, and if so it resend it again to the right handler.
- When a DLOAD/ULOAD request is lost, the state machine used by HandlePacket and DoRequery is getting stacked with m_state = STATUS_REQ_SENT. I've add a counter that reset the state to IDLE when DoRequery is called twice for the same request.
In amule-remote-gui.cpp:
- In PollTimer, I've removed the second request to EC_OP_STAT_REQ. This way we save some bandwidth. The info is now partially handled on the second state of PollTimer.
Finally, I've included two new functions to RemoteConnect in the EC lib: ResendLastPacket and FifoRemoveOne. Only the first one is actually used by the patch, and it resends the last packet to the last handler in the fifo, which should be the right one. The other funcion just removes that handler (not sending the packet again), and corrects the de-synchronization, but the packet is lost.
The patch was applied to the clean aMule-2.2.1 source code.
I hope this works for you people too!
-
This is very interesting. Thank you for your work! I'll look at your patch in detail, but it will take some time. (Or maybe someone else commits it tonight, who knows... ;) )
-
Unfortunately, we must first find what's wrong with the current code before hacking the behaviour.
I agree that some escurity measures to avoid aMuleGUI freaking out by some packets should be in place, but let's first make sure we don't do that, or we'll end up with a "sloppy" coded EC where errors like this are nt coded.
xor, it's a fantastic finding you did there, don't get me wrong. I just would like someone to take a closer look at the sympthoms.
-
Kry, I agree with you that devs should look carefully at the code before commiting this patch, and I'm not sure if it should be commited at all. It would be much better to fix the real problem instead of just make a workaround. I've sent it just to give other people a temporary solution (starting with me :)), and to clearly expose the problem.
On the other hand, when I debugged the amulegui <-> amuled behaviour, I dind't see anything wrong (meaning that no packets seemed to be lost) except that packets were not arriving to amuled in the order they were sent to it. I think this is not bad by itself, just amulegui should have a central handler that detects amuled replies and send them to the right handlers.
-
On the other hand, when I debugged the amulegui <-> amuled behaviour, I dind't see anything wrong (meaning that no packets seemed to be lost) except that packets were not arriving to amuled in the order they were sent to it.
I think this is a very bad thing to see, giving that not you, or me, or anyone at this point knows why that would be the case, which points to something really, really deep going on.
Your patch is good as a temporary workaround and it may (MAY) enter the next release if the reasons for the errors haven't been fixed by then. But I don't think it would enter the SVN.
Does that make sense?
-
I think this is a very bad thing to see, giving that not you, or me, or anyone at this point knows why that would be the case, which points to something really, really deep going on.
Your patch is good as a temporary workaround and it may (MAY) enter the next release if the reasons for the errors haven't been fixed by then. But I don't think it would enter the SVN.
Does that make sense?
OK, I'm not an amule dev, I don't know well how the protocol was planned and programmed, so please don't take what I've found as something 100% reliable (take it a 90% for example ;)). Maybe what's happening is not too serious. Only the people who programmed it can tell.
On the other hand, I've test my patch in three computers (two running mac os x, intel and ppc, and another one running linux), and it seems to work fine. More people should try it first before adding it to a next release.
For me it does make a lot of more sense to include the patch for a future aMule-2.2.x release that to commit it to SVN, providing no one else submits a better solution. For the SVN a proper solution has to be found. I'm not going to be upset if my patch is not being used, I've had a lot of fun debugging amule and learning how this wonderful software was programmed. If what I've found is useful, then much better.
-
xor, we'd need a lot of users like you since we're short on developers ;)
-
Hi again.
I'd finally found the amulegui real bug.
After properly debugging an amuled <-> amulegui session, I eventually discovered that amulegui sometimes fails to send a packet when its heavily loaded receiving and processing packets from amuled. This usually happens at the startup, when amulegui asks for the shared files and at the same time tries to send a request on transferring files. If you have a lot of shared files, there is more likely to force the bug. Also, you can force it just going to the shared files window and scrolling it up and down to force amulegui to ask more information on them.
The bug is in the EC library. amulegui calls SendRequest (in RemoteConnect.cpp), and it calls first WritePacket and then OnOutput (in ECSocket.cpp). WritePacket starts checking if there is a SocketError, a if it is, it return silently. But it shouldn't return if SocketError is due to WouldBlock, this is a normal situation.
To fix the bug just locate line 681 in ECSocket.cpp and change:
if (SocketError()) {
return;
}
to something like this:
if (SocketError()) {
if (!WouldBlock()) {
OnError();
return;
}
}
And enjoy! You can forget about my previous patch.
Some last words: even with the bug fixed, it is clear that amulegui is very sensitive to packet loosing. It is unlikely to lose packets in normal situations, but if they are lost the whole protocol gets desynchronized and it is not possible to recover it. Several solutions can solve the problem. One I've implemented is to write a central packet handler which detects amuled responses and sends them to the proper handler. If anyone is interested on this please let me know and I'll send a patch.
-
Hi xor,
thank you very much for keeping your teeth in this problem - if this works out, you will sure get the credit for finally making the remote gui usable!
Everybody's busy here with 2.2.2 at the moment, and I don't think this fix will make it into there, but it will be evaluated as soon as possible.
Please post also your packet handler patch.
-
The handler patch is attached here.
If a were you, for the 2.2.2 release I would include only the fix in ECSocket.cpp. It is easy to apply and it fixes the problem.
In any case, please, discard my previous patch. It's ugly and is just a workaround. This one I'm attaching is better, but it should be carefully tested.
-
The ECSocket change will be on 2.2.2, even if I remember me changing that and then finding something odd about the behaviour... but I assume you tested it extensively.
And if not, we'll blame you.
-
Sorry to hear that.
I just can say that I've tested it in a PPC Mac and a Debian Linux and it apparently works not affecting anything else. This is not an extensive test, but I cannot test it more, sorry. On the other hand, I can assure you that in is current state some packets that should be sent are not.
It's up to you to add the WouldBlock test or not. My amulegui is working fine by now, and for me it is enough to know that other people can patch and fix it if they want. If you are not sure (and being an aMule dev you have much more knowledge than I have on this), then just don't apply it and let other people to patch it if they want.
-
It is already added to SVN actually. And will be in 2.2.2. And if anyone complains, I'm going to tell them your email address.
I'm just that much of a bastard.
-
Good ol' Kry... ;)
-
That rocks! What a nice experience contributing to an open source project ;D
-
Feel free to do more of this, it's much appreciated. :)
-
Easy. 8) If amuleweb is not affected it might be just a problem of the remotegui-app.
My amuled server is a K6-II, 64mb computer and all network clients are Pentium4. amuleGUI works only on half each. And amuleweb always works perfectly for all. Sure! amuleGUI have some problem connecting but I prefer using it for distributing loads (I'm waiting lfroen adding xinet support for amuleweb :P)
I'm was able to confirm amulegui spending resources and getting limitated conectivity. I upgraded my server to athlon 256MB and all clients was able to connect correctly, so amuleGUI is spending high resources with a few clients (in my network it's true)
As I proposed time ago, from my point of view, amuleGUI will be better if we could select refresh time (real time, 2 minutes as amuleweb do, or so...)
I'm using same version of amule-CVS
Thanks for replies.
-
amulegui sometimes fails to send a packet when its heavily loaded receiving and processing packets from amuled. This usually happens at the startup, when amulegui asks for the shared files and at the same time tries to send a request on transferring files. If you have a lot of shared files, there is more likely to force the bug
Interesting :o
I keep my old k6, on safe place, for tests like this.Please, If I download current CVS, could I test that now?
PD: In all the ways I continue proposing control on update rate