Articles delegate-en/3110-3120 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
range 3110 - 3120   digest:
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-5bnwhwekjylr.ml@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-5bnwhwekjylr.ml@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-5bnwhwekjylr.ml@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-5bnwhwekjylr.ml@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-5bnwhwekjylr.ml@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
  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
Generated:12/13 19:33:36 (1 sec) Expires:12/14 01:33:35 @_@V