1-2 second pause between segment blocks

[seli 0]

I read this in one of the hubbs I'm in :

<matt> hmm.... gotta say.... I STILL dont like that 1-2 second pause between segment blocks on Apex...with a busy source, you can easily lose that slot in that brief but present delay.

<matt> heh... as i speak, i lost a slot on a pub hub. I still have to give the client a 1thumb up, one thumb down... for that reason alone

<matt> <---- closes the prog and waits for the next release

Is that a problem or do users simply don't understand how the program works?

Could one of you elaborate?

[Big Muscle 1]

They just don't understand how it works.

Yeah, there's the pause, but neither 1 nor 2 seconds, it's only a few miliseconds. I'm just guessing that this user has never counted how long the pause is and only says "it's 1-2 seconds"

also the phrase "you can easily lose that slot" is false. You can lose your slot only when you are not connected, but during this pause you are not disconnected and your slot is still held. I'm just guessing that this user has never lost slot in this situation and only says "you can".

[seli 0]

Ok, I'll spread the word :)

[bpmaxorz 0]

I would be "matt", in this case.

They just don't understand how it works.

Yeah, there's the pause, but neither 1 nor 2 seconds, it's only a few miliseconds. I'm just guessing that this user has never counted how long the pause is and only says "it's 1-2 seconds"

also the phrase "you can easily lose that slot" is false. You can lose your slot only when you are not connected, but during this pause you are not disconnected and your slot is still held. I'm just guessing that this user has never lost slot in this situation and only says "you can".

You are right, B_M....I don't fully understand how it works... I'm not a developer. I just call it like I see it.

The guess that I've "never counted how long the pause is" would be wrong.

The other guess that I have "never lost a slot" would also be wrong.

And I can prove it.

I made it a point before posting to make proof of "matt's" statements. I made screen recordings of the very things noted in that small hub. In the screen recordings, there are both 2-3 second pauses between segments (according to the client) , and a longer pause that lead to a slot loss. I welcome and encourage the developers to view my .avi screen recordings of the things mentioned at the top of this thread.

Before I get deemed as a trasher of the client, I want to point out that I currently run a 4 yr old hub, I know how to forward ports (otherwise, my hub wouldn't run), and I am not a noob. I am a veteran user of PW, Strong, and CrZ. The whole reason this thing came up is... none of the other clients ever exhibited the behavior outlined above. Apex has. That's it. I'm not here to bash or tarnish something that has obviously been carefully worked. I care about your effort, therefore, I speak.

Hopefully one of the dev. team will glance once again at this thread, and be curious enough to inquire with me about the screen recordings that I took the time and effort to make for the benefit of all. Most of all, I'd like Big Muscle to see the recordings... just so a guy I respect BIGtime doesn't think "matt" is an idiot. ;-)

[Crise 26]

Note when using DC++ emulation as far as i know loosing a slot is possible to keep the emulation working properly...

[Big Muscle 1]

There can be a pause. But realize what happens during this pause - client sends and receives one $ADCGET/SND command and it has about 140 bytes together. So if there's 1 second-long pause, it means that your connection speed is 140 bytes/second.

And take in account there's some pause. You can't lose your slot even in the case that this pause is 2 minutes, because your connection is not disconnected. You can lose slot only if you disconnect it or the remote user disconnects you.

I don't think that "matt" is idiot. He just says nearly what he sees. But it's like "hmm, progressbar stops and starts from the beginning, so there's one second pause (especially when the progressbar is updated maximally once per a second to decrease CPU usage) and I think that I can lose my slot" and this is only his thought, so he starts to spreads the guff over the network, so everyone will think the same :-/

[seli 0]

It's not my screenshots or recordings, but please have a look.

ApexDC Screens & Vids

bpmaxorz shared them in one of the hubs last night :)

[Big Muscle 1]

aah.. now I understand the whole problem. It's what Crise said.

If you have DC++ emulation enabled, then one segment needs to be disconnected when it gets to the part which is already downloaded and therefore you can lose the lost. It's because DC++ doesn't use chunked transfer so you can't request file by chunks but you must request it by whole file size. And current protocol has no command to cancel to transfer, so it must be completely disconnected. There's no such problem when DC++ emulation is not used (then it behaves how I described above)

And this has been discussed many many times.

[bpmaxorz 0]

Now that's a great explanation... thanks Muscle and Crise!

But (there's always a but) ...the crux of my point was this:

I use Strong and PW daily, and I have never seen an episode of the slot loss behavior in either of those clients, and I emulate in those, too. In Apex, I will lose a slot (as shown in that video) once every 15 minutes or so.

So what is the difference between these clients? Why does Apex do that and not the others?

[Big Muscle 1]

I think that Apex has longer pause beucase it sends partial info to all partial source before starting new chunk... but it's only my guess, so I can be wrong ;)

[Crise 26]

I think that Apex has longer pause beucase it sends partial info to all partial source before starting new chunk... but it's only my guess, so I can be wrong

You are quite right, however since version 0.3.0 (or was it 0.2.2) partial info (assuming you talking about $PSR here) is only sent to 20 sources and (by default) only if it has been at least 30 seconds since the last time the info was sent...

[Lee 84]

You are quite right, however since version 0.3.0 (or was it 0.2.2) partial info (assuming you talking about $PSR here) is only sent to 20 sources and (by default) only if it has been at least 30 seconds since the last time the info was sent...

And that is configurable in the Misc section.

[bpmaxorz 0]

Ah... now we're getting somewhere. Thanks, guys

I'm sure you can see how this might be a problem for some folks, particularly when having only a single busy source. It can be hours sometimes to re-attain a slot.

Now... would adjusting the "Delay when sending $PSR" up or down make a difference in this situation? Or maybe something else I can do in settings to reduce the instances of slot loss?

[Crise 26]

Ah... now we're getting somewhere. Thanks, guys

I'm sure you can see how this might be a problem for some folks, particularly when having only a single busy source. It can be hours sometimes to re-attain a slot.

Now... would adjusting the "Delay when sending $PSR" up or down make a difference in this situation? Or maybe something else I can do in settings to reduce the instances of slot loss?

Only thing you can do is increase the value of "Delay when sending $PSR" :)

[bpmaxorz 0]

Only thing you can do is increase the value of "Delay when sending $PSR"

I'll play around with it and see what kind of results I get. Thanks guys! You rock! ;)

[Big Muscle 1]

the best solution is not to use DC++ emulation ;)

[Zlobomir 3]

the best solution is not to use DC++ emulation

But sometimes it is not possible, just like active mode. The last time we discussed that I mentioned our "superseeding" feature remember Crise said ~ "Yes, technically it's possible". Hope it was regarding slots... :)

[Crise 26]

But sometimes it is not possible, just like active mode. The last time we discussed that I mentioned our "superseeding" feature remember Crise said ~ "Yes, technically it's possible". Hope it was regarding slots...

Mind refreshing my memory, since i can't follow here?

[Zlobomir 3]

Mind refreshing my memory, since i can't follow here?

No, I don't mind at all. Thanks to the perfect search engine, since for the protocol, it is 04:38 A. M. here.

http://forums.apexdc.net/index.php?s=&...post&p=6835

[Crise 26]

Ah, that was when i wasn't yet completely familiar with TBI's code... i don't remember what exactly i did mean there but that i can say that it wasn't anything in regards to slots...

[MiRaGe 0]

i also had/have this "slotloosing" problem, but i thought it's normal, cuz i had this with all multisource-clients

so you say if i don't use that dc++ emulation that will solve the problem?

should i skip dc++ emulation on all hubs if i wanna skip this problem or only on those hubs where my sources are? cuz there are some hubs which don't like multisource clients :)

[Big Muscle 1]

you can lose slot only in hubs where the emulation is enabled.

So, you are in 2 hubs A and B => A with emulation, B without emulation.

You have file with 2 sources - one is in hub A, the second one is in hub B.

So you can lose slot only for first source which comes from hub A where the emulation is enabled.

[Zlobomir 3]

you can lose slot only in hubs where the emulation is enabled.

So, you are in 2 hubs A and B => A with emulation, B without emulation.

You have file with 2 sources - one is in hub A, the second one is in hub B.

So you can lose slot only for first source which comes from hub A where the emulation is enabled.

The annoying thing in such cases, at least with me, is that when you have one source on 2+ hubs, usually it gives you only one slot (connection), from only one of the hubs, due to only one free slot of the source or using not multisource client maybe? So, on what basis Apex/other side chooses the hub, is it likely to choose the hub w/o emulation set? Not that I have noticed loosing a slot, but still...

[Big Muscle 1]

for ADC it selects correct hub, but for NMDC it's that one which is connected first.

A and B are the same-nick user but one from hub A and the second one from hub B:

Situation #1

* you connect to A

* A is connected and decided hub is correct A

* you connect to B

* B is connected and decided hub is correct B

Situation #2

* you connect to A

* you connect to B

* B is connected but decided hub is incorrect A

* A is connected but it will be disconnected due to unknown connection

[MiRaGe 0]

you can lose slot only in hubs where the emulation is enabled.

So, you are in 2 hubs A and B => A with emulation, B without emulation.

You have file with 2 sources - one is in hub A, the second one is in hub B.

So you can lose slot only for first source which comes from hub A where the emulation is enabled.

thanks a lot then i'll leave emulation on those hubs where multisourced clients are not banned :P