Official eMule-Board: Dynamic Block Requests - Official eMule-Board

Jump to content


Page 1 of 1

Dynamic Block Requests A way to significantly speed up eMule

#1 User is offline   netfinity 

  • Master of WARP
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1658
  • Joined: 23-April 04

Posted 10 November 2004 - 09:37 PM

An implementation suggestion, from the NetF 0.2d Mod, on how to defeat problems with download slots at different speeds and 'No Needed Parts'.

In extent to the changes provided below you also have to update the header files. In order to implement this you will need to know C++ as you have to do some coding yourself to adapt to the chunkselection mecanism used in your client.

DownloadClient.cpp - CUpDownClient::CreateBlockRequests
Just some changes to collect info about how much data we are waiting on to receive (requested blocks not yet processed) from the remote client.

Quote

void CUpDownClient::CreateBlockRequests(int iMaxBlocks)
{
ASSERT( iMaxBlocks >= 1 /*&& iMaxBlocks <= 3*/ );

// MOD BEGIN netfinity: Dynamic Block Requests
uint32 pendingBytes = 0;
uint32 transferredBytes = 0;
for (POSITION pos = m_PendingBlocks_list.GetHeadPosition(); pos != 0;){
  Requested_Block_Struct* block = m_PendingBlocks_list.GetNext(pos)->block;
  pendingBytes += (block->EndOffset - block->StartOffset + 1);
  transferredBytes += block->transferred;
}
if(transferredBytes < pendingBytes)
  pendingBytes -= transferredBytes;
else
  pendingBytes = 0;
// MOD END netfinity


if (m_DownloadBlocks_list.IsEmpty())
{
  uint16 count = iMaxBlocks - m_PendingBlocks_list.GetCount();
  Requested_Block_Struct** toadd = new Requested_Block_Struct*[count];

  if (reqfile->GetNextRequestedBlock(this,toadd,&count,pendingBytes)){ // netfinity: Dynamic Block Requests
  for (int i = 0; i < count; i++)
    m_DownloadBlocks_list.AddTail(toadd[ i]);
  }
  delete[] toadd;
}

while (m_PendingBlocks_list.GetCount() < iMaxBlocks && !m_DownloadBlocks_list.IsEmpty())
{
  Pending_Block_Struct* pblock = new Pending_Block_Struct;
  pblock->block = m_DownloadBlocks_list.RemoveHead();
  m_PendingBlocks_list.AddTail(pblock);
}
}


Partfile.cpp - CPartFile::GetNextRequestedBlock
This part is completly rewritten and it's here the calculations are done.
Note, that part selection has moved to MOD_FindNextPart() function!

Quote

bool CPartFile::GetNextRequestedBlock(CUpDownClient* sender, Requested_Block_Struct** newblocks, uint16* count, uint32 pendingBytes)
{
if (!(*count)) return false;    // added as in 29a
if (!(sender->GetPartStatus())) return false; // added as in 29a

uint16 requestedCount = *count;
uint16 newblockcount = 0;
*count = 0;

// MOD BEGIN netfinity: Seed random generator
if (sender->m_lastPartAsked == 0xFFFF)
  srand((unsigned int) sender + ::GetTickCount());
// MOD END netfinity

// MOD BEGIN netfinity: Check if an other part is to be chosen
if (sender->m_lastPartAsked == 0xFFFF || MOD_GetRequestedSizeInPart(sender->m_lastPartAsked) >= GetTotalGapSizeInPart(sender->m_lastPartAsked))
{
  if (!MOD_FindNextPart(sender))
  {
  //AddDebugLogLine(false, _T("PartFile::GetNextRequestedBlock - No needed part"));
  return false;
  }
  //AddDebugLogLine(false, _T("PartFile::GetNextRequestedBlock - New part chosen: part = %d"), sender->m_lastPartAsked);
}
// MOD END netfinity

// MOD BEGIN netfinity: Dynamic Block Requests - Calculate block request size
uint32 bytesToRequest = 3 * EMBLOCKSIZE;
uint32 bytesToDownloadInPart = GetTotalGapSizeInPart(sender->m_lastPartAsked) - MOD_GetRequestedSizeInPart(sender->m_lastPartAsked);
uint32 bytesToDownloadInFile = GetTotalGapSizeInPart(sender->m_lastPartAsked) - MOD_GetRequestedSizeInFile();
uint16 downloadingSourcesInPart = MOD_GetDownloadingSourcesInPart(sender->m_lastPartAsked, sender);
uint32 sourceDatarate = sender->GetDownloadDatarate();
uint32 fileDatarate = GetDatarate();
float rateFactor = 1.0;
if (fileDatarate > 0)
  rateFactor = (float) sourceDatarate / (float) fileDatarate;
bytesToRequest = min(bytesToRequest, bytesToDownloadInFile * rateFactor / 2);
bytesToRequest = min(bytesToRequest, sourceDatarate * 60);
bytesToRequest = min(bytesToRequest, bytesToDownloadInPart / (downloadingSourcesInPart + 2));
if (sourceDatarate < 1024 || bytesToRequest < 10240)
  bytesToRequest = 10240;
if (bytesToRequest <= pendingBytes)
{
  //AddDebugLogLine(false, _T("PartFile::GetNextRequestedBlock - Request already large enough"));
  return false;
}
bytesToRequest -= pendingBytes;
// Check if we should drop source to speed up file completion
//if (fileDatarate > 0 && downloadingSourcesInPart > 1 && sourceDatarate < 1024 && rateFactor * downloadingSourcesInPart < 0.3 && bytesToDownloadInFile / fileDatarate < 20)
//{
// AddDebugLogLine(false, _T("PartFile::GetNextRequestedBlock - Too slow"));
// return false;
//}
// MOD END netfinity

// MOD BEGIN netfinity: Remember last asked part (from Maella)
while(sender->m_lastPartAsked != 0xFFFF && newblockcount < requestedCount && bytesToRequest > 0)
{
  Requested_Block_Struct* pBlock = new Requested_Block_Struct;
  if(GetNextEmptyBlockInPart(sender->m_lastPartAsked, pBlock, bytesToRequest / (requestedCount - newblockcount)) == true){
  // netfinity: Decrease bytes to request
  uint32 bytesRequested = pBlock->EndOffset - pBlock->StartOffset + 1;
  if (bytesToRequest >= bytesRequested)
    bytesToRequest -= bytesRequested;
  else
    bytesToRequest = 0;
  // Keep a track of all pending requested blocks
  requestedblocks_list.AddTail(pBlock);
  // Update list of blocks to return
  newblocks[newblockcount++] = pBlock;
  *count = newblockcount;
  if (newblockcount == requestedCount)
    return true;
  // Skip end of loop (=> CPU load)
  continue;
  }
  else {
  // All blocks for this chunk have been already requested
  delete pBlock;
  // => Try to select another chunk
  sender->m_lastPartAsked = 0xffff;
  break;
  }
}
// MOD END netfinity

if (!(*count))
{
  AddDebugLogLine(false, _T("PartFile::GetNextRequestedBlock - Unexpected NNP"));
  return false;
}
return true;
}


Partfile.cpp - CPartFile::MOD_FindNextPart
This function is the original chunk selection code from CPartFile::GetNextRequestedBlock with the allocation of block requests removed. This function should return true if a chunk was found. It should also set sender->m_lastPartAsked to the chunk found.

Quote

bool CPartFile::MOD_FindNextPart(CUpDownClient* sender)


Partfile.cpp - CPartFile::GetNextRequestedBlock
This is the NetF way to collect blocks, but you can easily the original code and just do an adaption where the resulting block is limited to meet the bytesRequested.

Quote

bool CPartFile::GetNextEmptyBlockInPart(uint16 partNumber, Requested_Block_Struct *result, uint32 bytesRequested) /*const*/
{
Gap_Struct *firstGap = NULL;
Gap_Struct *currentGap;
uint32 block;
uint32 start;
uint32 end;
//uint32 blockLimit;

// Find start of this part
uint32 partStart = (PARTSIZE * partNumber);
// What is the end limit of this block, i.e. can't go outside part (or filesize)
uint32 partEnd = (PARTSIZE * (partNumber + 1)) - 1;
if (partEnd >= GetFileSize())
  partEnd = GetFileSize() - 1;

if(partStart > partEnd)
{
  AddDebugLogLine(false, _T("CPartFile::GetNextEmptyBlockInPart - Part beyond end of file!"));
  return false;
}

// Don't bother to check complete parts
if(GetTotalGapSizeInPart(partNumber) == 0)
{
  // Part is complete
  return false;
}

// Fast return if no block offset is needed
if(result == NULL)
{
  if (MOD_GetRequestedSizeInPart(partNumber) < GetTotalGapSizeInPart(partNumber))
  return true; // There are still unrequested blocks
  else
  return false; // All blocks have been requested
}

CList<struct dataBlock> availableBlocks;

// Find the first gap from the start position
for (POSITION pos = gaplist.GetHeadPosition(); pos != 0; )
{
  currentGap = gaplist.GetNext(pos);
  if(currentGap == NULL)
  break; // We are done!
  if(currentGap->start <= partEnd && currentGap->end >= partStart)
  {
  for(uint32 i = 0; i < 53; ++i)
  {
    uint32 blockStart = partStart + i * EMBLOCKSIZE;
    uint32 blockEnd = min(blockStart + EMBLOCKSIZE - 1, partEnd);
    if(blockStart > partEnd) break;
    if ((currentGap->start <= blockEnd) && (currentGap->end >= blockStart))
    {
    uint32    start = max(blockStart, currentGap->start);
    uint32    end = min(blockEnd, currentGap->end);
    struct dataBlock newBlock;
    newBlock.start = start;
    newBlock.end = end;
    availableBlocks.AddTail(newBlock);
    }
  }
  }
}

for (POSITION i =  requestedblocks_list.GetHeadPosition();i != 0; )
{
  const Requested_Block_Struct* cur_block = requestedblocks_list.GetNext(i);
  for (POSITION j =  availableBlocks.GetHeadPosition();j != 0; )
  {
  const dataBlock avail_block = availableBlocks.GetAt(j);
  if (avail_block.start <= cur_block->EndOffset && avail_block.end >=cur_block->StartOffset)
  {
    availableBlocks.RemoveAt(j);
    struct dataBlock newBlock;
    if (avail_block.start < cur_block->StartOffset)
    {
    newBlock.start = avail_block.start;
    newBlock.end = cur_block->StartOffset - 1;
    availableBlocks.AddTail(newBlock);
    }
    if (avail_block.end > cur_block->EndOffset)
    {
    newBlock.start = cur_block->EndOffset + 1;
    newBlock.end = avail_block.end;
    availableBlocks.AddTail(newBlock);
    }
    j =  availableBlocks.GetHeadPosition();
  }
  else
    availableBlocks.GetNext(j);
  }
}

if(availableBlocks.IsEmpty())
{
  AddDebugLogLine(false, _T("CPartFile::GetNextEmptyBlockInPart - No block found"));
  AddDebugLogLine(false, _T("CPartFile::GetNextEmptyBlockInPart - Part requested: %d  Part left: %d"), MOD_GetRequestedSizeInPart(partNumber), GetTotalGapSizeInPart(partNumber));
  return false;
}

block = (rand() + ::GetTickCount()) % availableBlocks.GetCount(); // netfinity: Use time to get more randomness
POSITION idx = availableBlocks.FindIndex(block);
const dataBlock avail_block = availableBlocks.GetAt(idx);
start = avail_block.start;
end = avail_block.end;

bytesRequested -= bytesRequested % 10240;
if (bytesRequested < 10240) bytesRequested = 10240;
if (bytesRequested > EMBLOCKSIZE) bytesRequested = EMBLOCKSIZE;
if(start + bytesRequested - 1 < end)
  end = start + bytesRequested - 1;


if(start > end || (start - partStart) / EMBLOCKSIZE != (end - partStart) / EMBLOCKSIZE)
{
  AddDebugLogLine(false, _T("CPartFile::GetNextEmptyBlockInPart - Block boundaries voilated: start = %d, stop = %d"), start, end);
  return false;
}

//AddDebugLogLine(false, _T("Found block = %d"), i);
if (result != NULL)
{
  result->StartOffset = start;
  result->EndOffset = end;
  md4cpy(result->FileID, GetFileHash());
  result->transferred = 0;
}
return true;
}

Additional functions to add in Partfile.cpp

Quote

uint32 CPartFile::MOD_GetRequestedSizeInPart(uint16 part) const
{
uint32 requestedSize = 0;
// Find start of this part
uint32 partStart = (PARTSIZE * part);
// What is the end limit of this block, i.e. can't go outside part (or filesize)
uint32 partEnd = (PARTSIZE * (part + 1)) - 1;
if (partEnd >= GetFileSize())
  partEnd = GetFileSize() - 1;

for (POSITION pos =  requestedblocks_list.GetHeadPosition();pos != 0; )
{
  const Requested_Block_Struct* cur_block = requestedblocks_list.GetNext(pos);
  if ((partStart <= cur_block->StartOffset) && (partEnd >= cur_block->EndOffset))
  {
  requestedSize += (cur_block->EndOffset - cur_block->StartOffset + 1) - cur_block->transferred;
  }
}
return requestedSize;
}

uint32 CPartFile::MOD_GetRequestedSizeInFile() const
{
uint32 requestedSize = 0;

for (POSITION pos =  requestedblocks_list.GetHeadPosition();pos != 0; )
{
  const Requested_Block_Struct* cur_block = requestedblocks_list.GetNext(pos);
  requestedSize += (cur_block->EndOffset - cur_block->StartOffset + 1) - cur_block->transferred;
}
return requestedSize;
}

uint16 CPartFile::MOD_GetDownloadingSourcesInPart(uint16 part, CUpDownClient* exclude_src) const
{
uint16 sourceCount = 0;
for(POSITION pos = m_downloadingSourceList.GetHeadPosition();pos!=0;)
{
  CUpDownClient* cur_src = m_downloadingSourceList.GetNext(pos);
  if (thePrefs.m_iDbgHeap >= 2)
  ASSERT_VALID( cur_src );
  if (cur_src && cur_src->GetDownloadState() == DS_DOWNLOADING && cur_src != exclude_src)
  {
  if (cur_src->m_lastPartAsked == part)
    sourceCount++;
  }
}
return sourceCount;
}

eMule v0.50a [NetF WARP v0.3a]
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)
0

#2 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 31 May 2005 - 01:52 PM

ThX 4 that code - just wanted to push it up so other modders might check it out :+1:

One request for the future: it'd be FAR more easier to implement this if you would supply a short description of what's to change instead of useless snippets; i.e. because nobody else I know has such a weird and confusing coding style and such a variety of sub functions/classes, e.g. usually one would create a function for some code that is called at least twice not only once :flowers:
Your ideas and codes are great but nearly useless for anyone else because to understand them one has to check out your mod and understand every single bit because each line is connected to other codes... :worthy: :lol:
0

#3 User is offline   Aenarion[ITA] 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 92
  • Joined: 03-April 05

Posted 06 December 2005 - 08:16 PM

But is better this code or this code??

This post has been edited by Aenarion[ITA]: 06 December 2005 - 08:17 PM

EX Dev of Ackronic

The best italian mod!!
0

#4 User is offline   BlueSonicBoy 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 396
  • Joined: 26-September 04

Posted 07 December 2005 - 01:32 AM

Aenarion[ITA said:

,Dec 6 2005, 03:16 PM]But is better this code or this code??
View Post


Is it better?

Dazzle's faster endgame, drops slower sources when there are no more sources available when the last or only part is completing.It stops a slow source locking the last 3 or 1 180Kb block. Instead you get the block(s) from a faster source. Hence Faster endgame.

Netfinity's Dynamic Block request is a far more complex piece of code which requests blocks of varying size dependent on the source transfer speed and the time left to completion.

Netfinity explains how the code works Here

Of course netfinity's solution will work for all parts, not just the last. But requires more code changes.

The official eMule tries to mitigate the problem these fixes address with a 2 block request for slow eMule clients and a 1 block request for very slow eMule clients.

Dazzle's code is a quick and simple fix for the worst effected part.

Netfinity's code is a complete redesign of the block requesting code.

Personally I think Dazzle's code is a nice patch for the existing official code.
Netfinity's code would be nice as the basis of the next official release! :devil: :flowers:

I won't say better because it's not a like for like comparison.

This post has been edited by BlueSonicBoy: 07 December 2005 - 01:34 AM

0

#5 User is offline   SlugFiller 

  • The one and only master slug
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 6988
  • Joined: 15-September 02

Posted 08 December 2005 - 10:14 PM

Quote

But is better this code or this code??

With Dazzle's code, slow sources are dropped to allow download from faster sources. Under optimal circumstances, your download speed(for that file) is equal to the maximal speed you can get from one client.
Mathematically: FileSpeed_Dazzle=Max(ClientSpeed)

With Netfinity's code, the blocks are divided into smaller blocks, assigned to different users, so all sources would be able to provide different parts of the file. Barring some serious issue, your download speed would be equal to the sum of all speeds you can get from all sources.
Mathematically: FileSpeed_Netfinity=Sum(ClientSpeed)

So, in case you can't figure out the math on your own:
FileSpeed_Dazzle = Max(ClientSpeed) <= Sum(ClientSpeed) = FileSpeed_Netfinity

Now tell me which do you think is better.
Why haven't you clicked yet?

SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.
SlugFiller rule #2: The first most efficient method is unsolicited eMails.
SlugFiller rule #3: If it started in a thread, it should end in the same thread.
SlugFiller rule #4: There is absolutely no reason to perform the same discussion twice in parallel, especially if one side is done via PM.
SlugFiller rule #5: Does it say "Group: Moderators" under my name? No? Then stop telling me about who you want to ban! I really don't care! Go bother a moderator.
SlugFiller rule #6: I can understand English, Hebrew, and a bit of Japanese(standard) and Chinese(mandarin), but if you speak to me in anything but English, do expect to be utterly ignored, at best.
0

#6 User is offline   fabtar 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 880
  • Joined: 14-March 04

Posted 18 January 2006 - 09:09 AM

I like this feature(and similar fastendgame) a lot but I'm not able(from the last changelog) to understand if developers has already introduced this to the 0.47 beta.

Do you know if this "Fast endagame OR dynamic B Req" is implemented in the emule 0.47 ? (perhaps they have called in another name in the changelog whcih I'm not able to decrypt.. =) ).

thanks in advance
0

#7 User is offline   BlueSonicBoy 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 396
  • Joined: 26-September 04

Posted 19 January 2006 - 09:49 PM

fabtar, on Jan 18 2006, 04:09 AM, said:

I like this feature(and similar fastendgame) a lot but I'm not able(from the last changelog) to understand if developers has already introduced this to the 0.47 beta.

Do you  know if this "Fast endagame OR dynamic B Req" is implemented in the emule 0.47 ? (perhaps they have called in another name in the changelog whcih I'm not able to decrypt..  =) ).

thanks in advance
View Post

AFAIK the devs have said they don't want to drop transferring sources, so I think 'faster endgame' is out. Dynamic block request is a greater undertaking! I think the devs have chosen to concentrate their efforts in other areas.
The code seems to be the same with regard to block size and the mechanism for trying to reduce 'locked' blocks, but I have only had a very cursory look. :-k
0

#8 User is offline   leexgx 

  • UK MAD FOR LESS
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 2533
  • Joined: 04-November 02

Posted 20 January 2006 - 01:51 AM

this code (probly netf is better as it does not drop sources) its silly to have to wait 29min for the reask coes of an slow uploader drop at end or an slow upload at all
2hrs coes an edonkey puts its hoarda into get the last chunk

most of this is with Small files as well (makes most users who use other p2p apps Run once there downloads stop alot)

( /me prods netf to make an mod that only includes this fix (fast end game) it works Very well before the other stuff you added into the mod that does not work or well)
in and around
0

#9 User is offline   SlugFiller 

  • The one and only master slug
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 6988
  • Joined: 15-September 02

Posted 20 January 2006 - 05:51 PM

The devs have made a statement, or rather zz made it for them, that dropping sources and asking for blocks of less than 180k is out of the question. While I can understand the prior, the latter does not seem reasonable to me.
Nevertheless, it means they won't implement either Dazzle's or Netfinity's solutions in the official client, at least until sufficiently frequent requests for it change their mind.
Why haven't you clicked yet?

SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.
SlugFiller rule #2: The first most efficient method is unsolicited eMails.
SlugFiller rule #3: If it started in a thread, it should end in the same thread.
SlugFiller rule #4: There is absolutely no reason to perform the same discussion twice in parallel, especially if one side is done via PM.
SlugFiller rule #5: Does it say "Group: Moderators" under my name? No? Then stop telling me about who you want to ban! I really don't care! Go bother a moderator.
SlugFiller rule #6: I can understand English, Hebrew, and a bit of Japanese(standard) and Chinese(mandarin), but if you speak to me in anything but English, do expect to be utterly ignored, at best.
0

#10 User is offline   leexgx 

  • UK MAD FOR LESS
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 2533
  • Joined: 04-November 02

Posted 20 January 2006 - 11:29 PM

this code is on my high ones that should be in emule (i need to make an list as i forget them)

with out it makes emule lame at downloading small files (just my option)

but probly many others, some even think emule Stops at 99.9% to make sure you share it for an extra hr or 2

some users are smart and stop and start the file somt times that starts it agane
some restart the client when thay want it to finish
wait 29 mins for next round of reask and twiddle there thingers thinking why is this 1mb-2mb file takeing so long

Netf option Only Kicks in at the Last chunk or last 1-2 mb from last time rembering (uneless its not in the code but it looks like it as the overhead made by asking for 10KB blocks all the way tho emule would slow it down) emule will make more overhead in the time it has had to Reask every client for an download agane, if this had been added no more overhead as download is done

New users/users of other p2p apps will just go back to there old p2p client as emule does this quite offen at the end of the file
in and around
0

#11 User is offline   leexgx 

  • UK MAD FOR LESS
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 2533
  • Joined: 04-November 02

Posted 18 February 2006 - 02:14 PM

i prefer this not to be ignored as i think this is quite inportant (more so for small files and the way users See emule when thay do there first small file search)

but it would solve the "why is this download taking so long its only 3mb" 90% of the time its an client that has been uploading at 0kb an sec (edonkey or emule trickle slot) that norm pushs an fast upload to stop coes the slow uploaders hog the parts

whats intresting is when this topic was posted it makes sences to put this into emule
in and around
0

#12 User is offline   netfinity 

  • Master of WARP
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1658
  • Joined: 23-April 04

Posted 25 February 2006 - 07:04 PM

On popular demand I'm working on a new simplified version of this feature which can be integrated directly into the official 0.47a client.

The test I running are so far quite promising, although the result is not as good as in NetF most small files atleast complete within 10 minutes. The new version is not expected to have any dropping of stalled download slots, but they doesn't happen that often (unless you are downloading from hybrids) and usualy only adds an other minute to the download time.

The new Mod I'm working on will have this feature, SafeHash [SLUGFILLER], FlushThread [SiRoB/MorphXT]and ReadBlockFromFileThread [SiRoB/MorphXT] in it. So Devs and Modders could just merge with it and get a killer mule right away!

Hope to be able to publish my result in a few days! :)
eMule v0.50a [NetF WARP v0.3a]
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)
0

#13 User is offline   BlueSonicBoy 

  • Magnificent Member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 396
  • Joined: 26-September 04

Posted 25 February 2006 - 10:46 PM

^^^
Push

netfinity, on Feb 25 2006, 02:04 PM, said:

On popular demand I'm working on a new simplified version of this feature which can be integrated directly into the official 0.47a client.
View Post

That's great news. I look forward to seeing that! :thumbup:
0

#14 User is offline   Ded 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 104
  • Joined: 27-June 03

Posted 28 March 2006 - 01:07 PM

netf i didn't understand which should be the MOD_FindNextPart function...
it has different arguments than the originale GetNextRequestedBlock...
please can you post the entire MOD_FindNextPart definition??

tnx in advance
0

#15 User is offline   netfinity 

  • Master of WARP
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1658
  • Joined: 23-April 04

Posted 28 March 2006 - 04:42 PM

@Ded
The code I used for that function is completly incompatible with the official client, that was why I told what it was supposed to do.

I have however made a new simpler version of DBR in my ESE Mod, that is copy-paste friendly. Check it out!

/netfinity
eMule v0.50a [NetF WARP v0.3a]
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)
0

#16 User is offline   fabtar 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 880
  • Joined: 14-March 04

Posted 29 March 2006 - 01:38 PM

netfinity, on Mar 28 2006, 04:42 PM, said:


@netF
I'll try your ESE next weekend!!Thanks for such MOD.
I hope devs 'll implement this feature in next emule.
0

  • Member Options

Page 1 of 1

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users