Articles delegate-en/3110-3120 of [1-5033] on the server localhost:7119

[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]

range 3110 - 3120 wide narrow   digest: none 100 200 400 800

Timeout issues   01/29-05:43 . 3110  feedback@delegate.org (Yutaka Sato) [51] ___ Hi, You can inspect the resolver problem by getting detailed log of it with RES_DEBUG=1 option. The problem can be solved by supressing the DeleGate's original resolver (Resolvy) and using the stand SSL disconnect problem   01/29-06:39 . 3111  feedback@delegate.org (Yutaka Sato) [89] ___ Hi, If you are using DeleGate as a HTTP proxy for SSL-Tunneling, and if you see "not half_duplex ?" in your logfile of DeleGate, you will be able to escape the problem by specifying as this: REMITTA Timeout issues   01/30-16:59 . 3112  Gertjan Klein <peugabdyi-qprr6uc2i3y6.ml@delegate.org> [147] ___ Yutaka, First of all, thanks for your help. I had RES_DEBUG=9 as commandline option. I've changed it to 1 as you suggested, which appears to result in less messages. I have tried this, but unfortuna   01/30-17:27 . 3113  feedback@delegate.org (Yutaka Sato) [29] ___ Hi, Sorry, I overlooked it. Then try RES_DEBUG="-1" for the maximum loglevel since the value is a bit mask. Also the option "-W4" will make detailed log for Windows specific operations. I suppose th   01/30-17:53 . 3114  Gertjan Klein <peugabdyi-qprr6uc2i3y6.ml@delegate.org> [37] ___ Yutaka, OK, thanks for that. Unfortunately, this makes things even more confusing (at least for me ;). A fragment of the log: As you can see, the delay is between two gettimeofday() calls :O. Could   01/31-02:39 . 3115  feedback@delegate.org (Yutaka Sato) [39] ___ Hi, Hmm... your window of the log is too narrow for me to identify where it is. If the log fragment is right before "{R} RES_order(CFDS,CFNDS)", it can be in the intialization in main(). I uploaded   01/31-03:09 . 3116  Gertjan Klein <peugabdyi-qprr6uc2i3y6.ml@delegate.org> [45] ___ Yutaka, Thanks again for your help! I have tried this executable with the following commandline: dg9_0_6-pre2dbg1.exe -v -P8080 RES_DEBUG="-1" -W4 RESOLV=sys SERVER=http FSV=sslway DGROOT="c:/progra   01/31-03:42 . 3117  feedback@delegate.org (Yutaka Sato) [33] ___ Hi, Sorry the executable seems broken so that it cannot do getpeername() and getsockname(). It might be linking problem... So I uploaded recompiled version dg9_0_6-pre2dbg2.exe, try this one please.   01/31-04:09 . 3118  Gertjan Klein <peugabdyi-qprr6uc2i3y6.ml@delegate.org> [41] ___ Yutaka, No worries. OK, tried that one. I can now reproduce the problem with the extra debugging info. Note that the amount of debugging data is now too much for the scrollback buffer of the Windows   01/31-04:47 . 3119  feedback@delegate.org (Yutaka Sato) [36] ___ Hi, We can see the DeleGate is delayed in scan_HOSTS0() function. To inspect what is going in it, I uploaded dg9_0_6-pre2dbg3.exe. Try it please. Cheers, Yutaka D G Yutaka Sato <y.sato@delegate.org>   01/31-05:01 . 3120  Gertjan Klein <peugabdyi-qprr6uc2i3y6.ml@delegate.org> [26] ___ Yutaka, Done; log at http://www.gklein.org/temp/dg_log3.txt It seems to be this line: (WIN) 51:47 [820] --- scan_HOSTS0 [HOSTS] Oddly enough, the same sequence appears way at the beginning of the lo

[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]

Generated:05/23 02:31:32 (1 sec) Expires:05/23 08:31:31 V