SSL Connecting Phase hangs

Does this happen only for connections made in ADCS hub? Or does it appear for NMDC/ADC secure transfers too? Do you have your TLS (not only TCP) port forwarded correctly?

Happens only in ADCS Hubs. I have forwarded 3 Ports, in one installation 63'333/63'344/63'355, other Installation 4422/4224/2244 (TCP/UDP/TCP), In NMDC Hubs Strong<->Strong TLS Connections works, but i don't know if it hangs too. (I'm no more active in NMDC Hubs, i only had test)
I have restart Strong many times, PCs run since day's without reboot ;), i never have disconnects of the DSL Line.

If i connect to a NMDC Hub and a ADCS at the same time, after some hour, no slot will given to any ADCS User. Allways the NMDC Users are "prefered", they can connect faster. :-D .. A ADCS User need "a minute", a NMDC User get the slot "immediately".

If Strong is fresh restarted, the connectings in ADCS Hub are much faster, If Strong runs for some hours, more and more User are only in Connecting. Now it was 1 User downloading, and 7 on "connecting", after Restart it was much better. After about 1-2 Min. all Slots busy. Have a look in 3-4 Hours.

3 Hours later, Same.
2 Users can download, 5 Users hang at "Connecting..."

Is my bug your bug?
Bug #247038
But, if so, your bug isn't fixed. (?)

I tried downloading filelist from all users in ADCS hub and I didn't experience any problem. Nearly all filelists have been connected fastly and downloaded correctly.

Ok I don't know if this is relevant but it is certainly possible that it is relevant, because I was having the very same issue... and after inspection it turned out to be openssl that was causing it (or rather the supplied binaries of it, more specifically the release version of libeay32.lib).

The reason why you haven't seen this hang happen is probably because you use debug builds for majority of the time, or am I wrong?

In any case, I sorted my problem by compiling openssl again... I don't know what kind of configuration you use to build it but there must be quite some differences because the libs I get are both (debug and release) around 0,7 and 3,7 mbs... while your release version of libeay32.lib is 27,6 mb. (I simply compiled using the defaults, with the exception of not using shared dlls as the format).

tbh. I am rather curious as to where the difference in size comes from and why you supply pre-compiled binaries to begin with (especially since you only do it for 32bit).

Ok, i "upgrade" one of my PCs to normal dc++ 0.708 and the problem is gone. (But i don't linke the design of normal dc++) :)
I found an other user that has the problem, and the upgrade fix him the problem too. I hope you fix the problem in 2.22 or so :-D

> I tried downloading filelist
ok, my problem not happen with filelists. Only with real files and not at downloading.

Crise: my libs are so big, because I compile them with link time code generation. If you don't do it, you will lose a lot of performance in whole application.

>> ok, my problem not happen with filelists. Only with real files and not at downloading.
But your problem seems to be in connecting phase. And it's only one regardless what you are downloading ;-)

I'm just going to test Release build now.

So, I don't see any problems with SVN 422 in release mode.

BigMuscle, i don't know if my problem exist with download. I can see it with upload only. And with upload of filelist it does not exist.

That connecting problem you see , does that happens the moment a slot comes free ?

There seem to be a piece of code in 2.21 that uses a future ADC extention called a active Q, as far i can see my strgdc sends out a DCM to the user that requered a slot the moment a slot is freed but the other client has no idea what to do with this and is not answering so it keeps hanging untill it times out , in the meantime that other client is trying to connect using the normal Q system and that offcourse doesnt work either untill the connection attempt from my side stops, as soon i disconnect that session the other users starts downloading ...

what is active Q?

http://adc.sourceforge.net/wiki/index.php/Extensions#UPQU_-_UPload_QUeue

The extention where the downloading client gets a "ticket number" and as soon a slot comes free the uploader sends a connect string to the downloader to start its download

It also sends a STA msg to a downloader when the uploader has no free slots, stating the his place in the Q,

I seen this problem since 2.11 and reported it also on the old bug page with the exact ADC commands that are send by the uploader .... but maybe it wasn't clear what i was typing lol :)

http://strongdc.sourceforge.net/forum/viewtopic.php?f=14&t=5320

Upload queue isn't original ADC extension. It has been made as StrongDC++ feature and later proposed as extension in ADC protocol.

Did not know that and its a wonderfull idea but @ this moment it causes exactely what you see in navsim' s screen shot a "connecting" downloader never starting to download.

Have a hard time explaning this lol :) but

Its easy to reproduce, make sure you have no upload slots left and 1 user in Q, open the CDM debug window and grant a slot to the waiting user you will see that ...

1) In the debug window the uploader sends a DCM to the downloader and they exhange the INF strings and then the downloader should send a GET string what never happens.

2) In the transfer window you see a hanging upload "connecting" attempt

as soon you manualy kill this attempt and the user retrys a connection the normal way he get his file, same happens when a slot is freed ...

And, how do i disable this upload Queueing?
Or come a new release up?
I like to come back to strong. Dc++ 0.708 is a horrible pice of crashing buggy shit. :-D (~3-4 crash / week)

You can not disable it , and version 2.22 still have the same prob alto it seems for the rest a fine piece of work regarding the transfers both in nmdc adc(s), love it.

From what i understoud there needs to be a patch in the dc++ part but am not a dev so maybe has some better info :)

Here is the info https://bugs.launchpad.net/dcplusplus/+bug/305811 :)