Official eMule-Board: Set Lastaskedtime When Processing Op_Outofpartreqs - Official eMule-Board

Jump to content


Page 1 of 1

Set Lastaskedtime When Processing Op_Outofpartreqs to save an unneeded TCP request

#1 User is offline   Enig123 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 495
  • Joined: 22-November 04

Posted 24 November 2016 - 07:45 PM

According to UploadQueue.cpp and UploadClient.cpp, if a downloading client send up an OP_OUTOFPARTREQS, it means that the remote client has already added us to it's waiting queue, and SendOutOfPartReqsAndAddToWaitingQueue() has been invoked, thus SetLastUpRequest() has been called.

On our side, SetLastAskedTime() should be called when processing OP_OUTOFPARTREQS, so that the immediate file request (TCP) can be avoided.

This post has been edited by Enig123: 26 November 2016 - 04:47 AM

0

#2 User is offline   fox88 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4515
  • Joined: 13-May 07

Posted 10 December 2016 - 03:03 PM

View PostEnig123, on 24 November 2016 - 10:45 PM, said:

so that the immediate file request (TCP) can be avoided.

Avoiding immediate request makes some sense.
Though, according to comment in CUpDownClient::SendOutOfPartReqsAndAddToWaitingQueue(), the reception of "out of parts" message does not always mean that really there are no needed parts.
Also, even on immediate reask client might get an upload slot if any were available.

This post has been edited by fox88: 10 December 2016 - 03:04 PM

0

#3 User is offline   Enig123 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 495
  • Joined: 22-November 04

Posted 10 December 2016 - 06:05 PM

View Postfox88, on 10 December 2016 - 07:03 AM, said:

Avoiding immediate request makes some sense.
Though, according to comment in CUpDownClient::SendOutOfPartReqsAndAddToWaitingQueue(), the reception of "out of parts" message does not always mean that really there are no needed parts.
Also, even on immediate reask client might get an upload slot if any were available.


Fox88, you're seeing the bright side. However, the inconsistency of the last time this client asked a file between this client and the remote client might cause this client been banned, in some rare cases.

Assume you got a downloading from a remote guy right before the next reask time, after received OutOfPartReq you think it's time for the reask and you did, while the remote client marked the previous reask time as just now, you got a badrequest++ in the remote side.

Worse situation is, the remote client was happy to give you another downloading, before the next 'normal' reask, the same situation will happen, and another badrequest++.

In this situation, you as a normal client be banned due to request flood in the end.
0

#4 User is offline   fox88 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4515
  • Joined: 13-May 07

Posted 11 December 2016 - 09:19 AM

View PostEnig123, on 10 December 2016 - 09:05 PM, said:

However, the inconsistency of the last time this client asked a file between this client and the remote client might cause this client been banned, in some rare cases.

How rare and what consequences it would have?
To get banned the situation must repeat 4 times in a row. Have you ever logged anything like that?

Now if you add half an hour 4 times, you will get noticeably more than 1 hour wait for lifting the ban. :)
0

#5 User is offline   Enig123 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 495
  • Joined: 22-November 04

Posted 11 December 2016 - 11:13 PM

View Postfox88, on 11 December 2016 - 01:19 AM, said:

To get banned the situation must repeat 4 times in a row. Have you ever logged anything like that?

Now if you add half an hour 4 times, you will get noticeably more than 1 hour wait for lifting the ban. :)


Actually I have noticed some suspicious client been banned on my side before, though I cannot be 100% sure it's exactly an example of the aforementioned situation.

To let the file asked time to be consistency between client and the remote one is the right thing to do, in any way.
0

#6 User is offline   fox88 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4515
  • Joined: 13-May 07

Posted 12 December 2016 - 07:57 AM

View PostEnig123, on 12 December 2016 - 02:13 AM, said:

Actually I have noticed some suspicious client been banned on my side before, though I cannot be 100% sure it's exactly an example of the aforementioned situation.

A single client, and even that one was not a sure case? That would be very weak supporting argument.

It might be preferable to allow quick reconnect in case of a network glitch while the risks of getting banned are small for well behaving client.
If the sutuation repeats over and over again, then either network connection malfunctions or the client is misused (for example, user manually reconnects many times in a row).

In conclusion, implementation of that idea will hardly make any noticeable difference.
0

#7 User is offline   pier4r 

  • Ex falso quodlibet ; Kad is the major concept behind emule.
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 566
  • Joined: 31-March 09

Posted 12 December 2016 - 09:40 PM

Sorry if I interrupt but, it exist a github, why not posting the issue there? Like a open repository was asked by many, but still people post on the forum.
>>> My wiki (ITA) on emule >>>Feature Request (ICS) or SOTN, ClientAnalyzer(fixing fastXs and reask punishment),, EmuleCollectionV2 >>> Emule on old hardware (intel pentium 2 or 3 - via c3 - and so on) with good OS settings and enough ram (256+ mb): great >>>user of: eMule - Xtreme - ZZUL bastard - SharX - SharkX 1.8b5 pierQR - ZZUL-Tra - ZZUL-Tra-TL - kMule - Beba

Extended signature: click.
0

  • Member Options

Page 1 of 1

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