5 Nov 10:02
Re: DC++ incompatibility
Robin Hill <robin <at> robinhill.me.uk>
2004-11-05 09:02:49 GMT
2004-11-05 09:02:49 GMT
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. > >>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 > >uploading/downloading so we get into this mess. The SrcLevel and > >DstLevel are supposed to work around this - whoever has the higher > >number gets priority. > > > In this case I'm a passive user (and the other user is active, > obviously), and if I've understood this correctly, that means that noone > can make contact with me directly, all requests to me will have to go > through the hub and all (tcp) connections will be set up by me. > > 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). 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. HTH, Robin -- -- ___ ( ' } | Robin Hill <robin <at> robinhill.me.uk> | / / ) | Little Jim says .... | // !! | "He fallen in de water !!" |
>
> >>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.
> >>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
> >uploading/downloading so we get into this mess. The SrcLevel and
> >DstLevel are supposed to work around this - whoever has the higher
> >number gets priority.
> >
> In this case I'm a passive user (and the other user is active,
> obviously), and if I've understood this correctly, that means that noone
> can make contact with me directly, all requests to me will have to go
> through the hub and all (tcp) connections will be set up by me.
>
> 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).
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.
HTH,
Robin
RSS Feed