S Murder

Connect to Hub in Queue

10 posts in this topic

You know how there's the option to connect to a favorite user's hub? Could the same option be added to each user in your download queue? For example, you could right click on a file in your queue, and just like for getting filelists or PMing, there will be a sub menu that says connect to user's hub, with a list of all the users from hubs you're not connected to.

Share this post


Link to post
Share on other sites

I am afraid that at least with the current NMDC protocol such info is not available, so there is no hub(s) to connect to. If I have misunderstood, pls clarify.

Share this post


Link to post
Share on other sites

I am afraid that at least with the current NMDC protocol such info is not available, so there is no hub(s) to connect to. If I have misunderstood, pls clarify.

Well, I was thinking that when you add a user as a source in your download queue, their hub IP and port # could also be stored in the queue's XML file, so Apex DC++ could retrieve that hub info and reconnect to it using an option when you right click in the download queue.

Share this post


Link to post
Share on other sites

Well, I have no experience or knowledge in coding, but shouldn't it be possible to just have that info saved in the queue too? (Which hub you found that specific user / file in originally)

Share this post


Link to post
Share on other sites

imo it is possible, just like in favs("URL="dc.hubname.com""), but remember the larger the queue - the higher the ram usage. also wouldn't this break compatibility with other clients? i'm against this feature unless it's an option :)

Share this post


Link to post
Share on other sites

and it won't be implemented, because they are not any hubs in queue. One user can be from more hubs (depending on protocol).

Share this post


Link to post
Share on other sites

and it won't be implemented, because they are not any hubs in queue. One user can be from more hubs (depending on protocol).

Well, not a great deal if 2+ hubs are saved, but what about resource waste? Maybe not having this part active, just when user sees file is "dead", he could choose "Show hubs peer has been in".

Share this post


Link to post
Share on other sites

You could right click and have 'connect to users last known hub'. Which, in theory, is great, but having said that, for someone like me, who queues up sometimes hundred's of files and leave the pc for weeks on end. It'd haul the ass outta even my 2Gb RAM.

Share this post


Link to post
Share on other sites

I don't see why it would make things so much harder. Here's an example (edited for privacy) of an entry in my download queue XML file:

<Download Target="C:\Downloads\Some File.avi" Size="256265408" Priority="5" FreeBlocks="14958577 354418688 355099737 366225408 " VerifiedParts="0 14 " Added="1187100947" TTH="HIIBWMOE4YYMYMT2GNQ3LMPSJYQ2QUN3BJZBWTQ" TempTarget="D:\Downloads\Some File.avi.HIIBWMEE4YYMYMT24NQ3LMPSJYG2QUN3BUZBWTZ.dctmp" Downloaded="11639526" AutoPriority="0" MaxSegments="4">

		<Source CID="Z2V6AJLFIIRX4WKUKXVPACFKQVO63WGVKY7UIXY" Nick="Nobody1000"/>

		<Source CID="BMVYN6EWVIWTYGYISZVC3CW6WYV54BDQ6S6NQZI" Nick="[abc]spaceman"/>

</Download>
To add the user's hub, all you'd really have to do is add another attribute to the Source tag containing the hub's IP + port #, and maybe another one if you wanted the hub's name and/or description. Example:
<Download Target="C:\Downloads\Some File.avi" Size="256265408" Priority="5" FreeBlocks="14958577 354418688 355099737 366225408 " VerifiedParts="0 14 " Added="1187100947" TTH="HIIBWMOE4YYMYMT2GNQ3LMPSJYQ2QUN3BJZBWTQ" TempTarget="D:\Downloads\Some File.avi.HIIBWMEE4YYMYMT24NQ3LMPSJYG2QUN3BUZBWTZ.dctmp" Downloaded="11639526" AutoPriority="0" MaxSegments="4">

		<Source CID="Z2V6AJLFIIRX4WKUKXVPACFKQVO63WGVKY7UIXY" Nick="Nobody1000" Hub="255.255.255.255:255"/>

		<Source CID="BMVYN6EWVIWTYGYISZVC3CW6WYV54BDQ6S6NQZI" Nick="[abc]spaceman" Hub="myhub.no-ip.org:1337"/>

</Download>

I might be mistaken, but I think when you add the same source more than once from different hubs, the same person appears once for each hub they're in, so each instance of that source would have it's own hub address stored with it. Even if duplicate sources were stored in one entry, the hub addresses could be stored as a comma separated list. It wouldn't be all that much more information stored in memory, Apex DC++ would just have to know to write that info to the queue when a source is added and read that information and connect to the specified hub when the user chooses the "Connect to Hub in Queue" option.

imo it is possible, just like in favs("URL="dc.hubname.com""), but remember the larger the queue - the higher the ram usage. also wouldn't this break compatibility with other clients? i'm against this feature unless it's an option :lol:

I think that would depend on how the other clients are coded. If they get the XML attribute nodes by name then adding extra entries won't make a difference, they'll just be overlooked. But, if they collect the attribute nodes as an array and iterate over every item based on it's index, adding extra elements might disrupt the order. That would be the fault of bad programming though, since relying on the index order of attributes disallows forward compatibility. As long as any custom attributes are put after the standard CID and Nick attributes though, it should still work even with poorly programmed clients.

Edited by S Murder

Share this post


Link to post
Share on other sites

It probably can be done... it's just "how to done it the smart way" and "is it worth the effort for dev."

Maybe it would require some tinkering ... but doing it the same way fav users are tracked for last hub address wouldn't be probably to much resourceful consuming.

Out of the recent suggestions I would vote for

A. searching downloaded FLs

B. checking if FL has changed and not re-download again*

* this would probably require some tinkering on other client also, but can be done.

Share this post


Link to post
Share on other sites