headers
Robin Hill | 4 Nov 22:08
Picon

Re: DC++ incompatibility

On Thu Nov 04, 2004 at 09:00:11PM +0100, Tommy Thorsen wrote:

> The background for this mail is the problem described in (at least) two 
> threads in the forum, namely:
> http://dcgui.berlios.de/forum/viewtopic.php?t=2363
> and
> http://dcgui.berlios.de/forum/viewtopic.php?t=2538
> 
> I've posted using the name SuperTommy.
> 
> The function CDownloadManager::DM_TransferCallBack() in the file 
> "cdownloadmanager.cpp" (line 3785 onwards, from "case DC_MESSAGE_KEY:") 
> contains some code where the hierarchy of if's looks like this pseudo-code:
> 
> 01: if ( Transfer->GetDstDirection() == Transfer->GetSrcDirection() )
> 02: {
> 03:     if ( Transfer->GetDstLevel() < Transfer->GetSrcLevel() )
> 04:     {
> 05:         if ( Transfer->GetSrcDirection() == edDOWNLOAD )
> 06:         {
> 07:             <change DstDirection to edUPLOAD>
> 08:         }
> 09:         else if ( Transfer->GetSrcDirection() == edUPLOAD )
> 10:         {
> 11:             <change DstDirection to edDOWNLOAD>
> 12:         }
> 13:     }
> 14:     else if ( Transfer->GetDstLevel() > Transfer->GetSrcLevel() )
> 15:     {
> 16:         if ( Transfer->GetSrcDirection() == edDOWNLOAD )
(Continue reading)

Permalink | Reply |
headers
Tommy Thorsen | 4 Nov 22:48
Picon
Favicon

Re: Re: DC++ incompatibility

Thanks for the quick response Robin :-)

>>Question 2: This is really my most important question; Why do we not try 
>>to change SrcDirection in line 22?
>>
>>    
>>
>Because it doesn't make sense here.  Both parties are trying to upload a
>file. but the other party has priority in this case, so they should
>switch direction or retry (if they're not wanting to download).
>  
>
I'm reaching this code when I try to download files from certain DC++ 
users. I haven't explicitly tried to upload anything. Are files (like 
filelists) automatically and secretly uploaded to the other party when I 
try to download from them?

If the other party has priority, shouldn't we yield and switch 
direction? Or do I misunderstand the nature of this priority?

>>Question 4: What does SrcDirection and DstDirection do anyway? It looks 
>>to me like they need do be different, right? One side of the 
>>communication should upload while the other downloads, is that it?
>>
>>    
>>
>Yes, usually they'll be different.  If everyone was active then theere
>wouldn't be a problem as you'd always be uploading to incoming
>connections and downloading from outgoing connections.  With passive
>users you just don't know whether someone connecting to you is
(Continue reading)

Permalink | Reply |
headers
Robin Hill | 5 Nov 10:02
Picon

Re: DC++ incompatibility

On Thu Nov 04, 2004 at 10:48:06PM +0100, Tommy Thorsen wrote:

> Thanks for the quick response Robin :-)
> 
> >>Question 2: This is really my most important question; Why do we not try 
> >>to change SrcDirection in line 22?
> >>
> >>   
> >>
> >Because it doesn't make sense here.  Both parties are trying to upload a
> >file. but the other party has priority in this case, so they should
> >switch direction or retry (if they're not wanting to download).
> > 
> >
> I'm reaching this code when I try to download files from certain DC++ 
> users. I haven't explicitly tried to upload anything. Are files (like 
> filelists) automatically and secretly uploaded to the other party when I 
> try to download from them?
> 
No, but it may be that they have a download queued from you which is not
running either beacuse you have no slots free or because they're
limiting the number of concurrent downloads.

> If the other party has priority, shouldn't we yield and switch 
> direction? Or do I misunderstand the nature of this priority?
> 
I'm not sure on this one.  I'd've thought we should switch direction if
we have a download waiting, though in this case we'd presumably have
started the transaction in download mode, not upload.
(Continue reading)

Permalink | Reply |
headers
Tommy Thorsen | 7 Nov 19:15
Picon
Favicon

Re: Re: DC++ incompatibility

Robin Hill wrote:

>That's right, yes.  When you want to download from someone then they'll
>connect to you.  Your client _should_ then be in download mode (as it
>knows it's wanting to download from this user) and the remote client is
>either in upload mode (in which case the download starts) or also in
>download mode (in which case the priority is looked at and you either
>switch to upload or the remote switches to upload).
>
>So, it may be that the problem is with the code whereby Valknut decides
>which mode to start in so it's starting in upload mode rather than
>download mode.
>
>  
>
I see that the CDownloadManager::CheckWaitTransfer() function returns 
edUPLOAD in this case, whereas it returns edDOWNLOAD when I try (and 
succeed) to download from other dclib-using people.

If I understand this function correctly, it checks whether there is a 
waiting transfer. If it can't find a pending download from this user, it 
concludes that this must be a request from the other client to download 
something from me, therefore my transfer-direction should be edUPLOAD.

Now, there should really be a transfer waiting, since I am trying to 
download from this person, but for some reason the nick and hubname used 
in the checks does not match any of the nicks and hubnames in the list 
of waiting transfers.

I've had some success putting this bit of code into the
(Continue reading)

Permalink | Reply |
headers
Robin Hill | 7 Nov 20:12
Picon

Re: DC++ incompatibility

On Sun Nov 07, 2004 at 07:15:47PM +0100, Tommy Thorsen wrote:

> Robin Hill wrote:
> 
> >That's right, yes.  When you want to download from someone then they'll
> >connect to you.  Your client _should_ then be in download mode (as it
> >knows it's wanting to download from this user) and the remote client is
> >either in upload mode (in which case the download starts) or also in
> >download mode (in which case the priority is looked at and you either
> >switch to upload or the remote switches to upload).
> >
> >So, it may be that the problem is with the code whereby Valknut decides
> >which mode to start in so it's starting in upload mode rather than
> >download mode.
> >
> I see that the CDownloadManager::CheckWaitTransfer() function returns 
> edUPLOAD in this case, whereas it returns edDOWNLOAD when I try (and 
> succeed) to download from other dclib-using people.
> 
> If I understand this function correctly, it checks whether there is a 
> waiting transfer. If it can't find a pending download from this user, it 
> concludes that this must be a request from the other client to download 
> something from me, therefore my transfer-direction should be edUPLOAD.
> 
> Now, there should really be a transfer waiting, since I am trying to 
> download from this person, but for some reason the nick and hubname used 
> in the checks does not match any of the nicks and hubnames in the list 
> of waiting transfers.
> 
<-- snip -->
(Continue reading)

Permalink | Reply |
headers
Mathias Küster | 24 Dec 15:03
Picon

Re: Re: DC++ incompatibility

Robin Hill wrote:
> On Sun Nov 07, 2004 at 07:15:47PM +0100, Tommy Thorsen wrote:
> 
> 
>>Robin Hill wrote:
>>
>>
>>>That's right, yes.  When you want to download from someone then they'll
>>>connect to you.  Your client _should_ then be in download mode (as it
>>>knows it's wanting to download from this user) and the remote client is
>>>either in upload mode (in which case the download starts) or also in
>>>download mode (in which case the priority is looked at and you either
>>>switch to upload or the remote switches to upload).
>>>
>>>So, it may be that the problem is with the code whereby Valknut decides
>>>which mode to start in so it's starting in upload mode rather than
>>>download mode.
>>>
>>
>>I see that the CDownloadManager::CheckWaitTransfer() function returns 
>>edUPLOAD in this case, whereas it returns edDOWNLOAD when I try (and 
>>succeed) to download from other dclib-using people.
>>
>>If I understand this function correctly, it checks whether there is a 
>>waiting transfer. If it can't find a pending download from this user, it 
>>concludes that this must be a request from the other client to download 
>>something from me, therefore my transfer-direction should be edUPLOAD.
>>
>>Now, there should really be a transfer waiting, since I am trying to 
>>download from this person, but for some reason the nick and hubname used
(Continue reading)

Permalink | Reply |
headers
Vesa-Matti Sarenius | 8 Nov 13:11
Picon
Picon

Re: Re: DC++ incompatibility


I tried to install the qt-3.3.3 (etc.) from the trolltech sources. The
installation went fine and I did it with ./configure -thread, but valknut
did not compile. Configure went fine, but compilation errored with missing
libqt-mt.a and true, that is missing. Only .la is found.

So the question: With what options should I compile qt-source to get
valknut to work?

--

-- 
Vesa-Matti Sarenius, M.Sc.       * Kun on joskus lähdettävä, *
mailto:sarenius.at.paju.oulu.fi *   taivaan tähdet jäävät     *
Finland, Europe.                 * öisin pimeään loistamaan. *
*   *   *   *   *   *   *   *   * Göstan muistoa kunnioittaen *
Permalink | Reply |
headers
Ion-Mihai Tetcu | 5 Nov 12:08
Picon
Favicon

Re: Re: DC++ incompatibility

On Fri, 5 Nov 2004 09:02:49 +0000
Robin Hill <robin <at> robinhill.me.uk> wrote:

>  > Is that right? And how does my passiveness affect the scenario where I 
>  > want to download something from someone?
>  > 
>  That's right, yes.  When you want to download from someone then they'll
>  connect to you.  Your client _should_ then be in download mode (as it
>  knows it's wanting to download from this user) and the remote client is
>  either in upload mode (in which case the download starts) or also in
>  download mode (in which case the priority is looked at and you either
>  switch to upload or the remote switches to upload).

How are these priorities defined/computed ?

-- 
IOnut
Unregistered ;) FreeBSD "user"

--

-- 
IOnut
Unregistered ;) FreeBSD "user"
Permalink | Reply |

Gmane