Print

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

[lfroen]

well for me this patch works:

            if(Kademlia::CKademlia::GetPrefs()->HasLostConnection()) {
                StopKad();
                clientudp->Close();
                clientudp->Open();
                if (thePrefs::Reconnect()) {
                    StartKad();
                }

Somewhere around line 1460 in amule.cpp.

But this is only a workaround because a new recvq is opened. Not the problem that the queue is becoming full is solved this way.

IMHO this is correct thing to do (re-open socket before restarting KAD). In general, I think that problem have origins in buggy UDP implementation on WX side.
The problem is that sometime WX stops delivering events about UDP packet received, which cause packets to be dropped, and network disconnected on timeout. Since socket remains open, WX remains in zombie state, and can as a result KAD can  not be restarted. When socket is closed, WX state is flushed, and KAD is reconnected.

[rapid2k1]

Maybe I can give a little more info about this. I'm using the cvs version of amule in a debian testing machine.  There is no NAT, no filter, no port forwarding. I have a direct cable connection, and my box is directly connected to the internet. iptables rules are per default set to accept.

ii  amule-cmd                           2.1.3+CVS20071029-1                 the amule-commandline-client
ii  amule-daemon                        2.1.3+CVS20071029-1                 the amule daemon
ii  amule-i18n-en-gb                    2.1.3+CVS20071029-1                 English (en_GB) internationalized (i18n) fil

After seeing this in the logfile:

2007-10-30 10:10:51: Disconnected from Kad
2007-10-30 10:10:51: Indexed.cpp(249): Kademlia Indexing: CInvalidPacket Exception in CIndexed::readFile: CInvalidPacket: Integer
tag expected, but found "^B"=Type=10
2007-10-30 10:10:51: RoutingZone.cpp(150): Read 182 Kad contacts

i did a status:

$ status
 > ED2K: Connected to xxx[xxxx:5000]  with HighID
 > Kad: Not connected
 > Download:    43.65 kB/s
 > Upload:      9.74 kB/s
 > Clients in queue:    1737
 > Total sources:       1928

not connected!, then, connect manually

aMulecmd$ connect kad
2007-10-30 11:10:51: Kad started.

couple of tries an minutes after:

aMulecmd$ status
 > ED2K: Connected to xxx[xxxx:5000] with HighID
 > Kad: Not connected
 > Download:    43.75 kB/s
 > Upload:      9.45 kB/s
 > Clients in queue:    1733
 > Total sources:       1936

[lfroen]

One the one hand

I'm using the cvs version of amule

but on the other

amule-daemon                2.1.3+CVS20071029-1

Hmm?

Actually, you did not added to your previous report. We see KAD running and then disconnected. We also see reconnection attempt failed for no particular reason.

[rapid2k1]

One the one hand

I'm using the cvs version of amule

but on the other

amule-daemon                2.1.3+CVS20071029-1

Hmm?

Yes, the debian package made by vollstreckernet (http://www.vollstreckernet.de/debian/)

Actually, you did not added to your previous report. We see KAD running and then disconnected. We also see reconnection attempt failed for no particular reason.

yes, thats because i call it "a bug". No particular reason and no warning/message. The first time amule is started, it connectes without problem. Then, after the first disconnection, it is unable to connect again, it doesn't matter if i use the connect option from the cli.

[lfroen]

Nobody seems to be arguing that this isnt a bug. No new information was, however, provided on a nature of this bug.
I still blame WX.

[phoenix]

lfroen,

If there is a workaround, as suggested by realcruncher, shouldn't we commit it? You seemed to agree with his solution.

Cheers!

[rapid2k1]

Nobody seems to be arguing that this isnt a bug. No new information was, however, provided on a nature of this bug.
I still blame WX.

Sorry if I sounded a bit harsh.

I'd like to point to this error:

2007-10-30 10:10:51: Indexed.cpp(249): Kademlia Indexing: CInvalidPacket Exception in CIndexed::readFile: CInvalidPacket: Integer
tag expected, but found "^B"=Type=10

Maybe it has something to do with Kadmelia not connecting again. However, the WX bug (wx closing udp ports and forgiving them) looks a good candidate. Shouldn't the proposed fix (closing/reopening) be commited, so we can try if that solves the problem?

[lfroen]

Nobody seems to be arguing that this isnt a bug. No new information was, however, provided on a nature of this bug.
I still blame WX.

Sorry if I sounded a bit harsh.

I'd like to point to this error:

2007-10-30 10:10:51: Indexed.cpp(249): Kademlia Indexing: CInvalidPacket Exception in CIndexed::readFile: CInvalidPacket: Integer
tag expected, but found "^B"=Type=10

Maybe it has something to do with Kadmelia not connecting again. However, the WX bug (wx closing udp ports and forgiving them) looks a good candidate. Shouldn't the proposed fix (closing/reopening) be commited, so we can try if that solves the problem?

I didn't actually checked the code to see whether "InvalidPacket etc" can actually disconnect KAD (it should not). In any event, I will commit fix for re-opening UDP socket.

[lfroen]

committed udp socket fix.

[Aethereal]

I am behind a NAT (port forwarded) and I always had the KAD disconnection bug.
I'm actually running  amuled CVS-20071105 and the reconnect now works fine. The log states that nearly every hour the connection is lost but then successfully re-opened, and I can still do KAD-searches after several of these disconnections.
It's still unknown why the disconnection happens, but at least  KAD is now usable (by me anyway, and with most ed2k servers out, it's a really good thing).
Thanks to all for the efforts!

[realcruncher]

Hi there,

i think the indexing error is just a symptom of the udp bug (incomplete data ?) and i also agree with the assumption that the bug is hidden in wxwidgets somewhere.

The workaround works for me since months but it is ugly because it looks like you have to link again with all your peers but i have no knowledge about wxwidgets and so maybe there is a better solution ?

Mabye you can set a flag to enable autoflush or something with wxwidgets or someone could open a bug report for the wxwidgets developers but then i wonder why nobody of them noticed this strange behaviour yet.

Anyways at least now i don't have to add this patch to amule any longer when i compile the cvs version

[rapid2k1]

For me this fix solved the problem. Amule is now always connected to Kad network. However, and since we are talking about bugs in wxwidgets:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp    62489      0 xx.xx.xx.xx:9362   xx.xx.xx.xxx:3404       ESTABLISHED6668/amuled

has this any sense? why is the receive queue always full (or very big) in some tcp transmissions? I'd could be understandable if the send-q is big, but... the recv.q?

[rapid2k1]

i think the indexing error is just a symptom of the udp bug (incomplete data ?) and i also agree with the assumption that the bug is hidden in wxwidgets somewhere.

Isn't there any "verbose" option in the wxwidget kit?

[Archmage]

I'm using the latest CVS and amuled don't seem to lost the connections anymore.

[RRT4]

see the log ('show log' in amulecmd), it disconnects and reconnects automatically

yesterday cvs version, few hours ago:
 
> 2007-11-22 15:34:03: Disconnected from Kad
> 2007-11-22 15:34:03: MuleUDPSocket.cpp(86): MuleUDPSocket: Shutting down Client UDP-Socket
> 2007-11-22 15:34:03: MuleUDPSocket.cpp(77): MuleUDPSocket: Created Client UDP-Socket at port 1759
> 2007-11-22 15:34:03: RoutingZone.cpp(150): Read 0 Kad contacts
> 2007-11-22 15:34:03: Connected to Kad (firewalled)
> 2007-11-22 15:34:09: Connected to Kad (ok)