Official eMule-Board: Problem Uploading To Shareaza In 0.44 - Official eMule-Board

There is a problem with uploads to shareaza clients in the 0.44 version of eMule. This topic is currently being disscussed in the shareaza forums. It will be a great help to the developers of shareaza if an eMule developer could help them solve the problem.

Shareaza Thread

Wouldn't it be far easier if they would read the eMule code to check how a proper implementation of ed2k should look like and then request a change or change their own client from there?

This is at least how aMule and xMule did it so far (Other ports as well I guess).

This post has been edited by Andu: 29 November 2004 - 11:20 PM

The main difference is that shareaza is not an eMule port. The code looks nothing alike and a shareaza developer (that never worked with the eMule code) can't just browse through all of emule's code and hope he will notice the problem...

Yes, it would be easier if everyone sat on their duff and pontificated. All problems would be easily solved .


http://forums.sharea...=&postid=193931

--> this above is an attachment to a post. It is a zip of two file captures, one with Shareaza uploading to emule, one of Shareaza trying to download from emule (which is the more interesting one), and having emule drop the connection. Likely it dropped shareaza because of something Shareaza sent, or didn't send but that emule was expecting. If anyone here is familiar with emule's protocol and code, it ought not be difficult for them to quickly ID the problem.

niRRity, on Nov 30 2004, 04:14 PM, said:

Do you think after a port like from eMule to aMule that the code looks much alike? Especially since none of the MFC libraries can be used?

The only thing that should be different between aMule and Shareaza is that aMule tried to copy the eMule implementation 1:1 while Mike had to reverse engineer the protocol and probably missed alot in the process.

If the Shareaza dev team really wants to get rid of this problem once and for all they have to read the eMule code in order to know how the protocol itself works. And then revise their own implementation of it. Otherwise you might end up with a working version for now but find the next problem with the next developments in the main ed2k clients.

Well its quite clear from the traces.

Shareaza sets the 'Extended Protocol' tag to 1. Which means that in extent to the file hash, part count and part map has to be sent which is not done.

Check the following link under section 4.2
eDonkey2000 Protocol

netfinity, on Nov 30 2004, 08:01 PM, said:

[OT]Thanks for that link. That's really a helpful documentation[/OT]

cya Skyw4lker

Hm didn't know that any real docutmentation of the protocol even existed. If that's the case bettering the implementation of Shareaza becomes much easier I'd say.

That is a very nice page. I'd only heard of one other page (besides the emule source code) that discussed the ed2k protocol with emule extensions.

I guess what most concerns shareaza is the note in section 4.2 on that hydranode.com page.

Quote

I'm still a bit fuzzy about what is wrong, and I don't understand the protocol very well. Shareaza doesn't appear to be using the emule extensions in its file request. Is it required since it says in the handshake just before that it supports emule extensions? If Shareaza added this bitarray partmap and complete sources, what protocol is the form of the packet? (I guess the answer to that is easy to find out I'll just run emule and look ).

This post has been edited by crf: 30 November 2004 - 10:03 PM

Much easier and just as pointless Andu...

crf, on Dec 1 2004, 12:01 AM, said:

True, it doesn't!

crf, on Dec 1 2004, 12:01 AM, said:

Yes, you have to send exactly those extensions as have been told in the handshake (important! the lowest number of the two clients is the extension version that should be used).

crf, on Dec 1 2004, 12:01 AM, said:

It will be identified as an eDonkey protocol but will be an eMule extension 2 protocol.

There is a reason to send what parts you have to the uploading client and that is to help it trim the list of sources sent to you by the source request, so it only contains those you need.

AFAIK, Shareaza does include the part map (if extended requests are enabled).

	QWORD nParts = ( pDownload->m_nSize + ED2K_PART_SIZE - 1 ) / ED2K_PART_SIZE;
	pPacket->WriteShortLE( (WORD)nParts );
	
	if ( pDownload->m_pHashsetBlock != NULL && pDownload->m_nHashsetBlock == nParts )
	{
  for ( QWORD nPart = 0; nPart < nParts; )
  {
  	BYTE nByte = 0;
  	
  	for ( DWORD nBit = 0; nBit < 8 && nPart < nParts; nBit++, nPart++ )
  	{
    if ( pDownload->m_pHashsetBlock[ nPart ] == TS_TRUE )
    {
    	nByte |= ( 1 << nBit );
    }
  	}
  	
  	pPacket->WriteByte( nByte );
  }
	}
	else
	{
  for ( QWORD nPart = 0; nPart < nParts; )
  {
  	BYTE nByte = 0;
  	
  	for ( DWORD nBit = 0; nBit < 8 && nPart < nParts; nBit++, nPart++ )
  	{
    QWORD nOffset = nPart * ED2K_PART_SIZE;
    QWORD nLength = min( ED2K_PART_SIZE, pDownload->m_nSize - nOffset );
    
    if ( pDownload->IsRangeUseful( nOffset, nLength ) == FALSE )
    {
    	nByte |= ( 1 << nBit );
    }
  	}
  	
  	pPacket->WriteByte( nByte );
  }
	}

It does not include (or advertise support for) the complete source count, since it would be difficult to calculate a meaningful value when it is not possible to determine which parts some clients have. (HTTP sources, etc)

I have been taking a look at the Shareaza source code. It's very clean and straight forward by the way.

I can't find anything wrong with the code. It should send those part maps, but it aint happening. The only explanation would be if m_bEmRequest accidentally gets resetted somewhere.

Just wanted to send you my appreciation (for what it matters) to all of you working on this issue. That's how things should work

Hmm, this is a bit of pickle then.

The capture I took defnitely shows that shareaza wasn't sending those things.

But at least it ought to be, so the problem is less large than it could be.

This post has been edited by crf: 01 December 2004 - 07:48 PM

I'll put a debug message in Shareaza to confirm it is sending the part map, but I already did a capture of eMule 0.44 and Shareaza file request packets, and they looked the same to me. (Same size, etc)

Click for picture


-edit-
Some interesting server stuff in that ed2k summary, though. No use for the current problem, but I think I'll take a closer look at what improvements can be made this weekend...

This post has been edited by MogTheCat: 02 December 2004 - 01:57 AM

Could these failed transfers have anything to do with trickle/standby slots? Maybe shareaza is dropping them for being too slow.

I wonder how that would be possible. The problem obviously occurs before the upload is actually initiatied. At least that's my impression after looking at my verbose log.

So whats eMule verbose log on this matter? This is actually the most effective way to find out whats wrong while sniffer captures just help to get in detail when the reason is clear

02.12.2004 14:11:36: Fehlerhaftes oder ungültiges Paket empfangen - while processing eDonkey packet: opcode=OP_REQUESTFILENAME size=16; Client=x.x.x.x 'Geminitm (shareaza.com)' (Shareaza v0.28,None/None)
02.12.2004 14:11:36: Added source to bad source list (Global) - file ??? : x.x.x.x 'Geminitm (shareaza.com)' (Shareaza v0.28,Error/None)


That seems to be the most common problem I could find. Applies to both Shareaza 0.28 and 0.30.

The german part just says that the packet was corrupt or faulty.